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Abstract: 


This  thesis  applies  and  extends  mathematical  program  verification  to  systems  programs. 
The  thesis  is  both  methodological  (in  proposing  a methodology  for  the  design  and  verification 
of  large  programs),  and  theoretical  (in  presenting  various  results  dealing  with  the  correctness 
of  parallel  programs). 

The  design  methodology  is  based  upon  the  use  of  abstract  data  types  and  the 
construction  and  verification  of  both  specifications  and  implementations  for  them.  The 
abstract  data  type  is  a means  of  modularization  which  encapsulates  the  representation  of  a 
data  structure  and  the  algorithms  which  operate  directly  upon  it.  The  specification  technique 
appeals  to  various  mathematical  structures  (eg.  sets  and  sequences)  to  describe  an  abstract 
state  for  objects  of  a given  type.  The  correctness  of  the  formal  specifications  is  cast  in 
terms  of  the  proof  of  certain  invariant  properties  of  the  abstract  state.  An  axiomatic  proof 
rule  IS  given  to  formulate  the  theorems  necessary  for  proving  the  invariance  of  predicates 
across  formal  specifications. 

The  applicability  of  the  methodology  to  operating  systems  is  explored.  It  is  found  that 
a hierarchical  decomposition  is  most  amenable  to  verification,  and  that  the  implementation 
language  used  is  a function  of  that  hierarchy.  The  example  of  a process  dispatcher  module 
of  a hypothetical  operating  system  is  used  to  illustrate  the  process  of  design,  specification, 
implementation,  and  verification  using  the  methodology.  Various  properties  are  proven  of  the 
abstract  specifications,  including  one  representation  of  the  concept  of  fair  service.  Programs 
are  then  written  for  the  specifications  and  their  correctness  is  verified. 

Three  different  approaches  to  the  total  correctness  of  parallel  programs  are  treated. 
The  first  uses  the  weakest  pre-condition  concept  to  explore  statically  the  combinatoric 
interactions  which  may  occur  among  parallel  programs  during  execution.  The  method  is 
complete  but  computationally  complex.  A second  approach  extends  the  axiomatic  weak 
correctness  results  of  Owicki  to  include  a technique  for  proof  of  loop  termination.  The 
concept  of  a steady  state  loop  invariant  is  introduced  and  used  to  establish  the  total 
correctness  of  an  old  scheme  of  mutual  exclusion  which  appeals  only  to  the  indivisibility  of 
memory  access  for  synchronization. 

The  third  approach  treats  a syntactically  restricted  class  of  parallel  programs.  For  this 
class  we  give  definitions  for  the  weakest  pre-conditions  which  guarantee  weak  correctness 
and  absence  of  blocking,  deadlock,  and  starvation.  We  also  formulate  theorems  which  use 
invariant  assertions  to  circumvent  the  actual  weakest  pre-condition  computation. 
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1.  Introduction 


Tile  primary  motivation  for  the  work  contained  in  this  thesis  is  the  desire  to  apply  and 
extend  mathematical  program  verification  to  the  realm  of  systems  programs.  It  has  long  been 
recognized  that  the  testing  and  debugging  of  large  programs  cannot  instill  much  confidence  in 
their  correctness,  since  it  is  rarely  possible  to  cause  large  programs  to  execute  all  possible 
paths.  Thus  there  has  been  a steadily  increasing  amount  of  research  done  to  discover 
methods  by  which  programs  may  be  statically  verified  - i.e.  deemed  correct  without  any 
execution  at  all. 

It  is  not  our  contention  that  run-time  debugging  should  be  totally  abandoned  in  favor 
of  correctness  proofs,  since  any  verification  of  a program,  be  it  mathematical  or  other //ise, 
requires  the  user  of  that  program  to  take  at  least  something  on  faith.  In  \'^e  case  of 
debugging,  we  must  believe  that  all  possible  inputs  (or  at  least  a covering  set  of  them)  have 
been  checked  against  their  outputs,  and  that  the  results  conform  to  those  predicted  by  the 
program  specifications.  In  the  case  of  mathematical  verification,  we  must  believe  that  aft 
necessary  theorems  have  been  proven,  and  we  must  believe  those  proofs.  In  either  case  we 
must  believe  that  the  program  specifications  are  themselves  correct. 

Of  late,  our  inherent  lack  of  confidence  in  both  of  these  verification  methods  has  led  to 
their  (at  least  semi-)  automation,  so  that  programs  now  exist  to  debug  other  programs  by  the 
generation  of  appropriate  test  data,  and  there  are  program  verifiers  which  attempt  to 
generate  and  prove  the  theorems  necessary  for  establishing  the  correctness  of  other 
programs.  Of  course,  we  have  merely  pushed  the  problem  off  a little,  since  we  are  now 
faced  with  believing  that  the  automatic  testers  and  verifiers  are  correct,  but  at  the  same  time 
we  somehow  gain  confidence  in  the  ultimate  correctness  of  the  target  programs. 

The  result  is  that  although  we  cannot  in  general  be  absolutely  certain  that  our  large 
programs  are  correct,  the  more  well-defined  verification  techniques  we  apply,  the  more 
confidence  we  gain,  and  confidence  is  absolutely  necessary  in  systems  which  perform  critical 
services. 

Returning  to  the  stated  purpose  of  our  research  with  some  conviction  as  to  its 
usefulness,  we  find,  alas,  that  really  large  programs  are  way  beyond  the  reach  of  known 
techniques  of  mathematical  verification.  This  is  due  to  the  vast  increase  with  program  size  of 
both  the  number  and  complexity  of  required  theorems.  Although  the  automation  of 
mathematical  verification  mentioned  previously  is  both  necessary  and  useful,  conventional 
verifiers  [Suzuki  75,  Good  75]  often  cannot  handle  the  complexity.  Thus  we  find  that 
large  programs,  which  are  not  verifiable  by  testing,  are  likewise  not  verifiable 
mathematically,  and  small  programs,  which  are  for  the  most  part  comoletely  testable,  are  the 
only  ones  which  can  be  completely  proved  correct.  This  has  not  only  caused  research  in 


ni.Tthcn'.atica)  verification  to  be  scoffed  at  by  industry,  but  has  resulted  in  the  discouragement 
of  many  researchers. 

Part  of  this  thesis  then,  Chapter  2,  deals  with  a methodology  for  verifying  large 
programs  by  making  them  a£pear_  to  be  srnall  programs  and  applying  known  techniques.  At 
this  point  we  might  merition  that  those  who  are  interested  in  verification  (from  here  on  we 
will  drop  the  prefix  "mathemaiical")  fall  roughly  into  two  camps  - those  who  are  interested  in 
techniques  to  verify  arbitrary  programs,  and  those,  like  us,  who  v/ill  settle  for  verifying 
prograrns  which  were  constructed  with  verification  in  mind.  It  is  our  firm  belief  that  all 
programs  can  be  so  constructed,  and  that  their  resulting  performance,  especially  in  view  of 
the  ever-faster  hardware  being  built,  can  be  made  to  be  very  close  to  that  of  programs 
written  with  only  performance  in  mind. 

We  have  thus  far  invoked  the  notion  of  a "correct"  program  several  times,  appealing  to 
an  intuitive  understanding  of  the  term.  The  meaning  of  correct  we  have  in  mind  requires 
something  to  compare  against  - i.e.  the  "right"  answer.  It  is  very  common  when  debugging  a 
program  to  find  that  the  wrong  answers  it  gives  are  due  to  an  unsatisfactory  or  inconsistent 
definition  of  correctness.  Thus  we  can  have  a correct  program  {with  respect  to  a given 
definition  of  correctness)  w'hich  is  con’ipietely  useless  for  the  problem  at  hand.  What  is 
needed  is  a description  of  what  the  program  must  do  in  a form  other  than  that  of  the 
program  text  itself,  so  that  we  may  operate  on  that  description  to  verify  it  without  having  to 
appeal  to  the  particular  implementation  choices  made  by  an  actual  program.  In  practice  the 
oescriptioo  often  takes  the  shape  of  prose,  but  prose  does  not  lend  itself  to  mathematical 
analysis.  In  Chapter  2,  we  discuss  the  relateci  problems  of  constructing  formal  specifications 
and  transforming  programs  info  something  that  can  be  conveniently  compared  with  them. 
Furthermore,  in  Chapter  2 we  discuss  an  approach  to  defining  the  correctness  of  formal 
specifications  themselves,  and  provide  a means  to  verify  that  correctness. 

In  Chapter  3,  we  are  concerned  with  the  application  of  the  methodology  of  Chapter  2 
to  operating  systems.  We  first  examine  the  relative  effects  of  system  structure, 
implementation  language,  and  verification  on  one  anotlier.  Subsequently  we  present  the 
design,  implementation,  and  verification  of  a process  dispatcher,  paying  attention  not  only  to 
proof  of  implementation,  but  also  to  proof  of  specifications  as  outlined  in  Chapter  2. 

Operating  systems  employ  a good  deal  of  concurrency,  and  satisfactory  techniques  for 
verifying  parallel  programs  are  not  yet  known,  although  work  is  beginning  to  be  done  on  the 
subject.  Owicki  [Owicki  75,  Owicki  76]  has  extended  the  work  of  Hoare  [Hoare  71a]  so 
that  tlie  insightful  addition  of  auxiliary  variables  to  parallel  programs  will  allow  them  to  be 
verified.  Griffiths  [Griffiths  74]  constructed  a system  which  could  verify  certain 
properties  of  parallel  programs,  although  the  method  depends  heavily  upon  the  properties  of 
the  ECL  [Prenner  72]  process  controller.  Habormann  [Habermann  72],  Flon  and 
Habermann  [Flon  76],  Howard  [Howard  76],  and  Saxena  [Saxena  76]  have  all  attacked 


the  problem  of  verification  applied  to  particular  synchronization  mechanisms  from  a data- 
rather  than  process-oriented  viewpoint.  In  Chapter  ^ we  explore  two  different  approaches 
to  verifying  the  total  correctness  of  parallel  programs.  The  first  uses  Dijkstra’s  weakest 
pre-condition  semantics  [Dijkstra  76]  to  consider  the  combinatoric  interactions  which  may 
occur  during  program  execution,  and  results  in  a complete  but  computationally  difficult 
method  of  verification.  The  second  approach  is  an  extension  of  Owicki’s  methodology  applied 
to  arbitrary  programs,  which  facilitates  proofs  of  strong  correctness  (loop  termination). 

Neither  of  the  two  approaches  of  Chaptt  • 4 appear  very  promising  for  automation. 

Since  the  verification  of  a large-scale  system  is  guaranteed  to  be  a large  project,  any  help 

whicli  can  be  provided  via  automation  is  welcome.  While  we  treat  a fairly  large  class  of 
parallel  programs  in  Chapter  4 without  much  automatable  success,  in  Chapter  5 we  discuss 
the  problem  of  parallel  program  verification  for  a restricted  syntactic  category  of  programs, 
and  present  well-defined,  automatable  methods  for  verifying  the  weak  correctness  of 
terminating  parallel  systems  (i.e.  verifying  their  output),  rnd  the  strong  correctness  of  non- 
terminating,  cyclic  parallel  systems.  In  particular,  we  give  a formal  definition  of  the  weakest- 
pre-ccndition  of  a cyclic  parallel  program  that  gua'-antee-  absence  of  blocking,  deadlock,  and 
starvation.  We  also  present  a verification  method  for  sirong  correctness,  along  the  lines  of 
the  invariant  method  of  sequential  loop  verification. 

Chapter  6 contains  a summary  of  the  results,  along  with  an  identification  of  the 

contributions  this  thesis  makes  to  the  field.  We  also  evaluate  the  feasibility  of  completely 

verifying  a useful  operating  system,  and  identify  wiiat  areas  require  more  research  to  make 
it  practical. 
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2.  Methodology 


2.1.  Programming  Language 

The  programming  language  in  which  a program  is  written  plays  a vital  part  in 
cietermmmg  the  amount  of  effort  required  to  verify  its  correctness.  We  shall  see  later  that 
the  specification  language  used  to  express  the  verification  goals  plays  an  equally  vital  part. 
For  the  moment  we  will  restrict  Ourselves  to  the  former. 


2.1.1  Level 

In  discussing  the  most  aoprcpriate  language  features  for  the  implement ation  and 
verification  of  large-scale  systems,  there  are  many  considerations  to  be  taken  into  account. 
Among  tile  most  important  are  expressiveness,  verifiability,  and  efficiency.  Historically,  the 
first  two  have  been  thought  by  many  to  be  in  conflict  with  the  third,  but  this  is  not  the  case. 
For  a long  time,  people  v/ere  unwilling  to  write  systems  programs  in  anything  other  than 
assembly  language.  This  was  due  both  to  the  inability  of  compilers  for  high-level  languages 
to  generate  efficient  machine  code,  and  to  the  inappropriateness  of  language  features  for  the 
problem  at  hand.  However,  since  the  early  years  of  compiler  development,  work  on 
optimization  has  enabled  compilers  to  generate  code  which  is  often  better  than  that  produced 
Py  experienced  systems  programrr.ers  (e.g.  [Wulf  75]).  There  is  no  question  as  to  the 
advantages  of  high-level  languages  for  verification.  This  is  due  in  large  part  to  the 
unprotected  nature  of  most  assembler  instructions  with  respect  to  the  ty'pe  and  scope  of 
values  which  they  may  change.  The  Algol  60  concept  of  restricted  scope,  for  example,  is  an 
invaluable  asset  when  it  corries  to  verifying  assertions  of  the  form  "and  there  is  no  other 
way  to  change  this  value." 

Better  expressiveness  is  not  quite  so  easily  attributed  to  high-level  languages,  but  it 
wil'  be  seen  in  succeeding  sections  that  the  abstraction  features  which  a compiler  can 
provide  play  a crucial  role. 


2.1.2  Modularity 

We  can  subsume  the  concept  of  scope  in  that  of  modularity,  since  if  the  scope  of  a 
variable  or  group  of  variables  is  to  be  limited  to  only  part  of  a program,  then  that  part  is 
separable  from  the  rest.  Exactly  what  constitutes  a module  is  the  subject  of  this  section. 


The  first  thing  we  must  ask  is,  "'What  arc  the  desirable  attributes  of  a good  modular 
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decomposition?"  One  is  that  each  module  should  constitute  a separate  work  assignrrient,  so 
that  small  groups  of  programmers  can  work  independently  of  one  another  (the  "too  many 
cooks"  syndrome).  Another  is  that  most  reasonable  changes  made  to  the  system  should 
require  explicit  alteration  of  as  few  modules  as  possible.  While  one  way  to  achieve  the  latter 
would  be  to  limit  ourselves  to  one  module,  this  is  effectively  prohibited  by  the  former.  A 
more  reasonable  way  to  achieve  localization  of  changes  is  to  assign  to  each  module  the 
responsibility  for  implementing  some  design  decision.  The  criteria  for  deciding  what 
constitutes  separable  design  decisions  are  certainly  open  to  discussion  (see  [Parnas  72b]), 
but  an  extremely  useful  principle  is  to  associate  each  module  with  the  implementation  and 
management  of  a class  Oi  data  structures.  Modularizing  along  the  lines  of  data  structure 
classes  results  in  small,  contained  sub-programs,  and  therein  lies  the  benefit  to  verification. 
When  assertions  about  the  properties  of  a data  structure  can  be  verified  once  and  for  all  by 
only  considering  the  implementation  of  a few  accessing  operations,  then  those  "invariant 
relations"  can  be  assumed  as  given  when  verifying  programs  which  use  those  operations. 
Otherwise  it  is  necessary  to  take  into  account  every  possible  program  statement  which  may 
change  the  structure,  and  there  may  be  very  many.  The  complexity  of  theorems  to  be 
proven  decreases  to  a more  manageable  size  if  code  to  actually  alter  a structure  occurs  in 
only  a few  places. 

This  principle  plays  an  important  role  in  th,e  methodology  we  propose  for  verifying 
large  prog'^ams,  and  manifests  itself  in  various  ways.  We  state  it  more  , recisely  here,  chiefly 
for  emphasis,  naming  it  the  Principle  of  Maximal  Encapsulation: 

The  usage  of  a program  module  should  never  affect  its 
correctness  (although  it  affects  that  of  the  user).  The  co.  rectness  , 
of  a system  decomposed  into  modules  is  then  determined  solely  by 
the  collective  correctness  of  the  individual  modules. 

If  the  principle  of  maximal  encapsulation  is  adhered  to  in  the  decomposition  of  a 
system,  then  the  verification  of  that  system  should  consist  of  a separate,  independent, 
verification  for  each  module.  It  is  only  by  this  application  of  the  divide  and  conquer  strategy 
that  we  can  hope  to  verify  a large-scale  system.  The  onus  is  then  placed  on  the  designers 
to  create  a good  decomposition,  but  that  is,  after  all,  where  it  belongs. 

2.1.3  Abstraction 


Having  decided  to  modularize  a system  on  the  basis  of  the  implementation  of  data 
structure  classes,  we  must  now  decide  on  the  representation  of  a module  in  a programming 
language  designed  to  support  verifiable  systems  programs.  Since  the  purpose  of  a module  is 
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1o  hide  the  details  of  the  implementation  of  a data  structure,  that  module  represents  an 
abstraction  to  its  users.  This  abstraction  takes  a behavioral  form,  as  in  for  exarriple 
describing  the  properties  of  a stack  without  considering  whether  it  is  implemented  as  a list 
or  an  array.  One  of  the  earliest  examples  of  linguistic  abstraction  in  programming  is  the 
subroutine.  The  subroutine  as  it  existed  even  m the  earliest  version  of  FORTRAN  provides 
the  programmer  with  the  means  to  1)  invoke  the  same  program  segment  from  several  places, 
thiis  raving  multiple  coding;  2)  parametrize  that  program  segment  so  that  several  similar  but 
slightly  difierent  segments  could  be  collapsed  into  one;  3)  defer  the  coding  of  a program 
segment  untii  necessary,  or  to  permit  someone  else  to  work  on  it;  4)  hide  the  details  of  an 
algorithm  from  a programmer  so  as  not  to  have  them  Interfere  in  his  own  task. 

The  subroutine  (or  procedure  as  it  came  to  be  known  in  Algol  60)  is  clearly  an 
important  concept,  but  is  not  in  itself  sufficient  to  provide  the  modularity  we  desire.  Because 
we  want  modules  to  restrict  data  structure  access,  we  must  not  allow  those  data  structures 
to  be  declared  in  such  a way  as  to  permit  direct  access  by  other  than  the  "privileged"  code 
of  a certain  p’-ocedure.  In  basic  Algol  60  syntax,  the  data  must  therefore  be  declared  local 
to  the  procedure  which  will  operate  upon  it.  This  cannot  be  done  when  miore  than  one 
procedure  must  have  the  direct-access  privilege.  To  solve  the  problem,  v/e  need  to  be  able 
to  "encapsulate"  the  data  declarations  along  wdh  the  applicable  procedures  in  one  textual 
unit. 


The  fired  attempt  at  this  kind  of  encapsulation  was  the  class  concept  of  Simula  67 
[Dahl  63].  There  has  been  much  v/ork  since  'which  has  refined  that  approach.  A discussion 
of  the  basic  issues  ma'/  be  found  in  [Liskov  74],  and  in  [Flon  74]  along  with  a comparison 
of  Simula  67,  Algol  68,  and  Pascal  along  tnese  lines.  Current  research  efforts  include 
['vVulf  75,  Schaffert  75,  Popek  77,  Ambler  77,  Geschke  77,  Johnson  76]. 

The  refined  syntactic  mechanism  has  come  to  be  known  as  the  abstract  data  type. 
Type  is  an  equivalence  relation  which  partitions  program  data  into  classes  based  upon  the 
operations  applicable  to  each  class.  The  abstract  data  type  provides  the  means  to 
accomplish  a very  natural  extension  of  the  set  of  data  types  pre-defined  in  a language. 
These  pre-defmed  types  usually  include  at  least  integer  and  boolean,  and  possibly  real.  Each 
of  the  so-called  "primitive"  types  is  characterized  Dy  a set  of  abstract  values,  such  as  the 
boolean  values  TRUE  and  FALSE,  m addition  to  type-specific  operations,  such  as  the  boolean 
functions  AND,  OR,  and  NOT. 

To  extend  the  set  of  types,  a programmer  m-ust  describe  both  the  behavior  and 
internal  reprc>'entatiori  of  objects  of  the  new  type.  The  implementation  details,  namely  the 
representation  used  ('which  we  will  call  the  structure'  and  the  algorithms  which  implement  the 
operations,  are  the  design  decisions  which  the  new  data  type  hides  from  users.  A 
description  of  the  abstract  values  and  the  behavior  of  the  operations  is  provided  to  users 
through  the  module  specifications. 
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As  a brief  example,  consider  the  extension  of  the  set  of  types  with  the  new  type 
"complex",  which  is  intended  to  model  the  behavior  of  values  in  the  complex  plane.  The 
abstract  values,  then,  are  ordered  pairs,  and  the  behavior  of  such  operations  as  complex 
addition  or  multiplication  is  the  same  as  vector  arithmetic.  A type  definition  in  our  language 
will  take  the  form: 

type  typename  = 

<structure> 

<operations> 

endtype 

If  we  had  such  a definition  for  complex",  we  would  be  able  to  use  it  in  a subsequent 
program  as  follows: 

var  x,y,z:  complex; 

x<-complex.create(l,2); 

y«-complex.cr  eat  e(  2.-3); 

z<-complex.mul(x.y); 

Mere  we  assume  that  the  call  "complex.create(a.b)"  creates  an  object  of  type  complex  with 
abstract  value  a+bi  by  invoking  the  "create"  operation  of  the  type,  and  that  the  call 
"complex. mul(x,v)"  invokes  the  "mul"  operation  of  type  complex  on  the  values  x and  y, 
returning  the  product.  Then  x = l+2i,  y=2-3i,  and  z=8+i  afterwards  (if  the  implementation  of 
"complex"  IS  correct).  One  definition  of  "complex"  might  be 

type  complex  = 

var  re:real,  im:real; 

CP  mul(x:complex,y:complex):complex  = 

complex.create(x.re*v.re-x.im*y.im,  x.re*y.im+x.im»y.re); 

4 

I 

endtype 

^ while  another  might  be 

I 

i 


V'us."'- 


8 


type  complex  = 

var  rho:real.  lheta:real; 


op  muUx:complex.y :compiex)xomplex  = 

complex.creale(x.rho*y.rho,  x.theta+y.thsta); 


endtype 

In  this  way  we  are  able  to  hide  from  users  both  the  representation  (rectangular  or 
polar  coordinates)  and  the  algorithms. 

Using  abstract  data  types  as  our  modularization  tool,  we  have  a means  to  adhere  to 
the  principle  of  maximal  encapsulation.  Since  it  is  possible  to  directly  alter  an  object  only 
from  Within  the  scope  of  that  object’s  type  definition,  only  the  operations  defined  therein  can 
e'fect  that  alteration.  If  the  operations  defined  are  not  too  primitive  (i.e.  if  they  don’t  defeat 
our  whole  pu''pose  by  allowing  arbitrary  assignment  to  critical  subfields)  and  if  they  are 
careful  to  check  their  parameters,  it  should  be  possible  to  have  absolute  faith  in  the 
consistency  of  the  data  structure.  Subsequent  sections  will  discuss  the  concept  of  data 
structure  consistency  more  formally. 


2.2.  Specification  Language 

The  question  of  how  to  write  formal  specifications  for  the  abstract  data  types  which 
cornprite  a system  is  very  important,  for  it  impacts  not  only  the  difficulty  of  constructing 
those  specifications,  but  also  the  complexity  of  verification  - both  the  verification  of  a 
particular  data  type  im.plement ation  and  that  of  "global"  properties  of  the  system.  An 
example  of  the  latter  distinction  is  the  difference  betv.een  verifying  that  a ready-process 
queue  always  has  a valid  queue  structure,  and  verifying  that  processes  on  the  oueue  are 
serviced  m FounO  Robm  fashion.  We  will  examine  three  specification  techniques  here  which 
seem  currently  to  be  the  most  promising.  Liskov  and  Zilles  [Liskov  76]  present  several 
specification  techniques  along  with  a similar  type  of  analysis,  although  we  shall  draw  some 
differeni  conclusions  from  thems.  We  disagree  also  on  the  classification  scheme  used. 

The  three  methods  can  all  be  classified  as  "axiomatic",  in  that  in  each  case,  a complete 
specific  at  ion  consists  of  a finite  set  of  rules  which  1)  sufficiently  describe  the  desired 
properties  of  an  object  in  a manner  which  in  general  allows  for  many  different 
implementations  (in  the-  sari.e  way  that  a given  set  of  axioms  of  first-order  logic  allows  many 
different  interpretations),  and  2)  when  combined  with  rules  of  inference,  provide  the  means 
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for  deductive  proofs  of  theorems.  The  axiomatic  methods  are  widely  differing  though,  and 
this  can  be  attributed  to  differences  in  form  as  well  as  rules  of  Inference.  We  further 
classify  the  methods  as  1)  algebraic,  2)  state  machine  oriented,  and  3)  predicate  transforming. 

2.2.1  Algebraic  Specifications 

Algebraic  specifications  have  been  examined  by  Guttag  [Guttag  75]  and  discussed  in 
[LisKov  76].  The  term  "algebraic"  stems  from  a formal  basis  in  heterogeneous  algebra.  The 
reader  who  is  interested  in  further  details  is  referred  to  [Guttag  75].  From  a practical 
point  of  view,  the  algebraic  specifications  of  a data  type  consist  of  a domain-r ange 
description  of  its  operators,  and  a series  of  axioms  which  define  those  operators  in  terms  of 
their  relationships  to  one  another.  As  an  example  consider  the  algebraic  specification  of  a 
type  "queue"  (in  fact  a FIFO  queue)  of  elements  of  some  other  type  t,  similar  to  that 
presented  in  [Guttag  75]. 

Domains  and  Ranges: 

newq:  -*  queue 
enq;  queue  X t queue 
deq:  queue  queue 
first:  queue  -*  t 
empty:  queue  -♦  boolean 

Axioms:  q:queue,  k;t 

empty(newq)  = true 
empty(enq(q,K))  = false 
first(newq)  = error 
first(enq(q,k))  - if  empty(q)  then  k else  first(q) 
deq(newq)  = error 

deq(enq(q,k))  =«  if  empty(q)  then  newq  else  enq(deq(q),k) 

Each  axiom  equates  a call  upon  one  of  the  operations  with  a primitive  recursive  function. 
The  set  of  axioms  comprises  a "sufficiently  complete"  description  of  the  notion  of  FIFO  queue. 
For  our  purposes  we  will  take  this  to  mean  "all  necessary  cases  are  accounted  for"  (see 
[Guttag  75]  for  a more  formal  definition  of  sufficient  completeness  and  for  a discussion  of 
its  proof).  The  presence  of  the  term  "error"  in  the  specifications  is  a means  of  expressing 
those  cases  which  should  never  occur  in  any  program  correctly  using  these  specifications. 

The  algebraic  specification  technique  exhibits  a pleasing  structure  in  this  case,  as  it 


<create  an  empty  queue> 

<create  a queue  with  an  element  appended  to  taii> 
<create  a queue  with  an  element  removed  from  head> 
<return  value  of  head  element> 

<test  for  empty  queue> 


docs  in  many  other  such  examples.  One  of  its  deficiencies  is  the  purely  mathematical  nature 
of  the  functions  which  are  specified.  In  the  mathematical  sense,  functions  do  not  cause  state 
chanf;es.  In  particular,  there  is  no  way  to  express  that  the  deq  operation  should  remove  a 
queue  element  and  return  that  element  as  its  value.  This  problem  is  inherent  in  the  formal 
basts.  It  has  been  proposed  [Guttag  77]  that  the  mechanism  be  extended  with  the 
definition  of  comiposite  functions,  such  as 

deqfirst(x,q)  = x»-first(q);  q<-deq(q) 
although  this  appears  to  be  somewhat  ad  hoc. 

A second  problem  with  the  technique  is  reflected  by  the  non-existence  of  axioms 
which  define  enq  explicitly,  and  can  be  seen  in  the  specification  of  a bounded  queue: 

length:  queue  -*  integer 

lcngth(ne'x<q)  = 0 
lcngth(enq2(q,K))  = l+length(q) 
deq(newq)  = error 

deq(enq?(q,k))  = if  empty(q)  then  k else  enq2(deq(q),k) 
enq(q,k)  =■  if  length(q)  > m then  error  else  enq2(q,k) 

Here  we  are  forced  to  invent  an  auxiliary  operator,  enq2,  in  order  to  allow  the 
detection  of  "error"  upon  insertion  of  a new  element  in  a full  queue.  In  addition  to  the  lack 
of  intuitive  interpretations  for  these  new  operators,  a programmer  may  be  mislead  into 
believing  them  to  be  necessary  in  the  implementation.  The  reader  should  convince  himself 
that  if  such  an  operation  is  not  used,  then  "error"  can  only  be  detected  at  the  point  a "more 
than  full"  queue  is  used  for  examining  or  dequeueing. 

These  problems  detract  somewhat  from  the  pleasing  mathematical  elegance  of  the 
technique,  but  they  are  not  really  sufficient  evidence  upon  which  to  base  our  evaluation. 
There  are  two  other  problems  that  seem  rriore  serious  from  our  point  of  view.  The  first 
deals  with  the  issue  of  specifying  the  behavior  of  objects  which  are  used  by  concurrent 
processes.  The  algebraic  techniqi.ie  provides  no  help  for  us  in  this  problem  simply  because 
the  purely  functional  nature  of  the  specifications  admits  no  notion  of  the  interference  and 
non-determinacy  introduced  by  concurrency.  The  other  problem  is  associated  witJa  the 
verification  of  particular  imiplementations  for  algebraic  specifications.  The  basic  idea  in  such 
a verification  is  to  examine  each  axiom  in  turn,  and  prove  that  the  left  and  right  sides 
compute  the  same  function  when  the  programs  are  substituted  for  the  abstract  operators. 
For  example,  if  an  axiom  for  type  "boolean"  were 


(1)  imp(a,b)  « or(not(a),b) 


and  the  programs  were: 


1 1 


imp(a,b)  = i_f  a=0  then  1 else  b fi; 
or(a,b)  = d a = l then  1 else  b fi; 
not(a)  = d a=0  then  1 else  0 fij 

then  or(not(a),b)  becomes 

(2)  d (lL  3=0  then  1 else  0 y=l  then  1 else  b h 

or  (3)  if,  a=0  then  1 else  b fj. 


which  is  imp{a,b),  and  axiom  (1)  would  be  verified. 

The  problem  with  this  strategy  is  that  it  relies  heavily  on  program  transformation  such 
as  that  between  (2)  and  (3)  above.  For  most  real-life  examples,  the  substituted  programs  do 
not  transform  into  one  another  easily,  as  the  reader  would  discover  in  attempting  to  verify 
an  Algol-like  implementation  of  type  "queue".  Additionally,  each  operate*'  occurs  in  several 
places  in  the  axioms,  and  therefore  its  implementation  program  must  be  cc  m.bined  with  other 
programs  many  times,  which  gives  one  the  feeling  that  the  same  prograra  must  be  verified 
over  and  over  again  (in  actual  fact,  smaller  and  different  aspects  of  the  programs  are  really 
being  verified  at  each  stage,  but  that  does  not  make  it  proportionally  easier). 

Finally,  users  of  the  algebraic  specification  technique  admit  to  the  fact  that 
constructing  such  axioms  for  non-trivial  types  is  difficult,  although  they  claim  that  experience 
does  help.  There  is  some  question  in  our  mind  as  to  why  the  difficulty  should  exist.  We  feel 
that  most  of  the  problem  is  due  to  the  fact  that  the  way  we  visualize  structures  is 
significantly  different  from  the  algebraic  approach,  and  we  would  therefore  prefer  a 
mechanism  with  which  it  is  easier  to  translate  our  thoughts  into  mathematics. 

2.2.2  Slate  Machine  Model 

( 

. The  state  machine  model  for  specification  is  due  to  Parnas  [Parnas  72a],  and  was 

adopted  by  the  group  at  SRI  concerned  with  the  design  of  a provably  secure  operating 
system  [Neumann  74].  It  is  based  on  the  notion  that  an  object  is  controlled  by  both 
passive  (information  gathering)  and  active  (state  transforming)  functions.  The  passive 
, functions,  called  V-functions  (V  for  value),  have  no  side  effects  whatsoever.  They  simply 

i return  information  about  the  current  state  of  an  object.  The  active  functions,  called  O- 

functions  (0  for  operation),  change  the  stale  by  altering  the  values  of  V-functions.  The  only 
relevant  program  state  is  in  fact  contained  in  the  values  of  all  the  V-functions.  In  the  case  of 
the  bounded  queue,  such  specifications  would  be: 


'/rrr 


12 


y,l:integer 

V-function:  k*-first 

purpose:  returns  first  queue  element 
initially:  undefined 
exceptions:  length=0 

V-function:  L^Length 

purpose:  returns  length  of  queue 
initially:  0 
exceptions:  none 

hidden  V-function:  k'-eKj) 

purpose:  returns  j'th  queue  element 
initially:  undefined 
exceptions:  j<0  v j>length 

0-function:  enq(k) 

purpose;  inserts  k as  last  queue  element 

exceptions:  length>m 

effects: 

1)  length=’length’+ 1 

2)  if  ’length’=0  then  first=K 

3)  el(length)=k 

0-function;  deq 

purpose:  reiTiOves  first  queue  element 

exceptions:  length<0 

effects: 

1)  length-’length’- 1 

2)  first=’er(l) 

3)  Vj;l<j<length:  el(j)='er(j  + 1 ) 

V-function  names  in  single  quotes  refer  to  the  previous  value. 

A problem  with  this  specification  technique  arises  from  the  fact  that  0-functions  are 
described  purely  in  terms  of  resulting  changes  to  V-functions.  This  introduces  a "delay" 
effect,  in  that  the  deq  function  above  has  no  way  to  define  the  resulting  value  of  first,  purely 
in  terms  of  ’first’  and  ’length’.  This  forces  the  introduction  of  the  hidden  V-function,  "el", 
which  IS  not  callable  from  outside  the  queue  module  (c.f.  the  "enq2"  operation  of  the 
algebraic  specifications,  with  all  the  same  criticisms). 
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In  order  to  verify  an  implement  at  .On  for  an  abstract  state  model  specification,  it  is 
necessary  to  define  "mapping  V-functions"  which  map  the  abstract  state  onto  the  program 
state.  For  example,  we  might  have 

map(lengfh);  I (a  program  variable) 

map(first):  fieacfT  (dereference  the  pointer  to  the  head  element) 

map(eKj)):  f(head,j)  where  f(x,y)=if  y=0  then  xT  else  f(xT.next,y- 1 ) 

for  a linked  list  implementation  of  the  queue.  Then  the  verification  of  a particular  function  F 
with  exceptions  <t>  and  effect  'p,  consists  of  proving 

map(<l>)  {program  F}  mapfifr) 

The  notation  is  that  of  Hoare  [Hoare  69]  and  is  read  "if  mapfit)  is  true  and  program  F is 
invoked,  then  map('Ir)  will  be  true  when  it  terminates." 

This  kind  of  specification  has  a more  manageable  verification  method,  since  the  proof 
of  expressions  like  that  above  is  well  understood  [Hoare  69,  Floyd  67].  We  still  find 
that  the  lack  of  an  explicit  representation  for  the  type  of  object  in  question  is  a problem,  as 
it  IS  with  algebraic  specifications,  forcing  the  designer  to  invent  "hidden"  operators  whose 
only  purpose  is  to  take  its  place. 


2.2.3  Predicate  Transformations 

Both  of  the  above  specification  techniques  are  representation-independent.  That  is, 
the  specifications  make  no  reference  to  particular  data  structures,  thus  leaving  that  decision 
to  the  implementor.  We  have  seen  that  in  many  cases  the  purely  functional  approach  forces 
the  introduction  of  "hidden"  operators,  and  we  asserted  that  these  hidden  operators  are 
merely  a way  around  making  use  of  actual  structures.  This  is  particularly  evident  from  the 
abstract  state  machine  model  example,  where  the  hidden  V-function  "el"  strongly  suggests 
the  use  of  an  array.  Of  course,  the  implementor  is  by  no  means  forced  to  use  an  array  - 
that  just  happens  to  be  a convenient  "abstract  representation." 

We  feel  comfortable  with  the  use  of  abstract  representations  in  the  specification  of 
abstract  data  types,  because  of  our  confidence  in  the  combined  data/control  nature  of  the 
cfata  type  mechanism  itself.  Since  no  purely  data-oriented  nor  control-oriented  mechanism  is 
sufficient,  there  is  no  reason  to  believe  that  either  should  be  sufficient  as  a specification 
technique. 

If  the  specification  of  an  abstract  data  type  includes  a mathematical  representation, 
then  the  specification  of  the  operators  can  be  given  in  terms  of  their  effect  on  that 


representation,  rather  than  in  ternis  of  their  effect  on  each  other.  That  effect  can  be  stated 
in  terms  of  predicate  transformation  In  the  sarne  way  that  the  effect  of  primitive 
prograiTiming  language  features  is  described.  The  proof  procedure  given  here  is  largely 
based  on  the  work  of  hioare  [Hoare  72b]  for  the  verification  of  Simula  classes,  and  the 
subsequent  development  by  the  Alphard  group  at  CMU  [Wulf  76].  We  shall,  however,  use 
weakest  pre-condition  semantics  [Dijkstra  76]  for  our  specifications  and  verification  instead 
of  the  w'eak  correctness^  method  of  Hoare  [Hoare  69].  Appendix  A contains  the  necessary 
definitions.  The  reader  who  is  not  entirely  familiar  with  this  approach  should  read  the 
Appendix  before  continuing. 

Every  cfata  t>pe  has  both  an  abstract  (mathematical)  and  a concrete  (programrrung 
language)  representation  or  structure.  Additionally,  each  operator  has  both  an  abstract  and 
concrete  implementation.  The  task  of  verifying  the  correctness  of  an  implementation  consists 
of  showing  that  it  is  a valid  model  for  the  specifications.  To  accomplish  this,  it  is  necessary 
to  define  a mapping,  c-/,  from  the  concrete  representation  to  the  abstract  one. 

Axioms  for  operations  take  the  form 

P(X)  { F(X)  } Q(X) 

which  is  interpreted  as  "H  P(X)  holds  and  F(X)  is  executed,  Q{X)  will  hold  whenever  F(X) 
lerminaies."  Then,  to  verify  this  axiom  for  the  abstract  object  X and  program  F,  against  the 
concrete  object  x and  program  f,  we  must  prove 

P(f^(x))  =»  wpfffx),  Q(r..y(x)) 

which,  by  the  nature  of  wp,  guarantees  that  the  operation  will  terminate.  To  carry  out  this 
proof,  it  is  necessary  that  the  function  f./  be  well-defined  both  before  and  after  the 
execution  of  each  concrete  operation  - otherwise  the  verification  is  meaningless.  If  we 
characterize  the  domain  of  c-.^  as  the  set  of  concrete  objects  which  satisfy  J,  i.e. 

domainfF./)  = {c  | J(c}} 

then  if  we  can  show  the  invariance  of  J across  each  operator,  we  can  assert  that  is  well- 
defined.  The  method  by  which  this  invariance  is  proven  is  presented  in  [Wegbreit  76] 
under  the  name  of  Generator  Induction,  and  was  indicated  informally  in  [Hoare  72b].  Let  the 
operators  of  type  t be  Oj,  i(l..n,  and  let  the  set  of  objects  of  type  t be  T.  Furthermore,  let  P 


* IVV.7A-  correctness  is  input-output  correctness  without  tornimation  Sl/ong  correctness  is  termination  only  Forfiol 
copfActness  »»  to  weak  correctness  Total  correctneps  tnciudes  both  weak  and  strong  correctness. 
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be  (VxtT)  J(k).  Tr.en  if  P is  preserved  by  each  Oj,  J is  invariant  for  t.  Note  that  this 
formulation  allows  for  the  creation  of  new  objects  by  any  operator,  as  long  as  they  are 
initialized  to  satisfy  J.  It  is  assumed  that  this  is  the  only  way  to  create  new  objects. 


2 2.4  The  Character  of  Abstract  Predicates 

We  indicatea  in  section  2.1.3  that  new  data  types  are  built  up  out  of  existing  ones. 
This  IS  done  by  applying  structuring  mechanisms  to  those  types.  These  structuring 
mechanisms  consist  primarily  of  arrays,  records,  and  references  [Flon  74].  Since  we  are 
to  define  mathematical  rep’-esent aticns  for  the  abstract  types  we  specify,  these  are  only 
naturally  created  by  applying  mathematical  structuring  mechanisms  to  other  abstract  types. 
Because  we  have  not  restricted  ourselves  to  any  particular  syntactic  form,  we  are  free,  in 
principle,  to  use  any  mathematical  notions  which  we  find  appropriate.  This  somewhat 
disconcerting  thought  - d.sconcerting  because  we  might  all  be  required  to  be  mathematicians 
programmers  in  order  to  read  or  construct  soecif icaf ions  - is  fortunately  not  so  terrible 
after  all.  It  appears  that  a small  number  of  concepts  suffices  for  most  purposes.  These 
include  the  notions  of  set,  sequence,  vector,  and  cartesian  product.  Taking  the  axioms  of  set 
theory  as  given,  we  can  define  the  other  concepts  axiomatically  as  is  done  in  [Hoare  72a]. 
A series  of  definitions  is  given  in  Appendix  B,  and  should  be  scanned  before  continuing 
further. 

As  an  example,  consider  the  bounded  queue  discussed  previously: 

Abstract  representation:  sequence(t) 

Let  S:sequence(t), 

m;integer,  <the  maximum  queue  length> 

x,K:t, 

qrqueue 

Operator  axioms: 

length(S)<m  A q=S  { enq(q,K)  ) q=S~K 
q»K~S  { x‘-deq(q)  ] x=k  a q=S 
q=k~S  { x»-first(q)  ) x=«k  a q=k~S 


We  give  an  implementation  for  these  specifications  as: 


type  queue(t :type,  ni:inteser)  = 

y ar  V:array  [0..m-l]  tj 
head.tail:ir.ter,e''; 

op  create(q:q'jeue)= 
i_f  m<0  then 
else 

head‘-0;  t ail<-0 

Ll: 

P£  enq(q:gyeu^l<:U= 

d q.tail-q.head>m  then  error 
else 

q.V[q.tait  mod  m]*-!*,; 
q.tail'-q.tail*! 

lb 


op  deq(q:oueue):t  = 

i_f  q.tail<q  head  then  eTor 
else 

q.head*-q.head+ 1; 
q.V[(q,head- 1)  mod  m] 

lb 


0£  first(q:queue):t  = d q.tail<q.head  then  error  else  q.V[q.head  mod  m]  f| 


endtype 


We  define  r.i/(q)  = seq(q.V,q.head,q.tail-l ),  where 

seq(V,i,j)  = V[i  mod  m]~V[(i  + l)  mod  m]~...V[j  mod  m],  if  i<j 
= X if  i>j. 

We  will  drop  the  prefix  "q."  in  what  follows.  TJote  that 

length(o.;/(q))  * length(seq(V,head,tail- 1 )) 

» (tail-1  mod  m)  - (head  mod  m)  + 1 
“ tail-head 


17 


Additionally,  we  require 


J = 0<tail-head<m  a rri>0  a tail>0  a head>0 
The  fact  that  J is  .nvariant  can  be  derived  as  follows: 

( 1 ) J ^ wp(enq(q,k),  j) 

J =>  wp(enq(q,k),  0<tail-head<m  a m>0  a tail>0  a head>0) 

J =*  tail-head<m  =>  0<*ail-head+l<rn  a rp>0  a tail>-l  a head>0 

true 


(2)  J =»  wp{x‘-deq(q),  J) 

J =»  wpfx'-deqfq),  Ost ail-head<m  a m>0  A tail>0  a head>0) 
J =»  tail>head  =»  1 <tail-head<m  + l a m>0  a tail>0  a head>-l 

true 


<3)  true  =>  wp(create(q),  J) 

wp(creafefq),  0<tail-head<m  a m>0  a tail>0  a head>0) 
m>0  A 0<0<m  A m>0  A 0>0  A 0>0 

true 


It  remains  to  verify  the  operator  axioms.  For  enq,  we  must  prove 

length(S)<m  A G-?'(q)=S  =»  wp(enq{q,k),  (q)=S~k) 
The  post-condition  expands  to 


S~k  = seqfv, head, tail-1 ) 


Then, 


wp(enq(q,k),  S~k=seq(V, head, tail-1 ))  = 

tail-head<m  a S~k=seq(<V,tail  mod  m,k>,head,tail)  » 
tail-head<m  a S~k=seq(V,head,tail-l)‘“k  = 
length(S)<m  a S=?.:/(q) 
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Sirniiarly,  for  deq  we  must  prove 

r>:/(q)=k~S  wp(x‘-deq(q),  r.;/(q)=S  A x^K) 
The  post -condition  expands  to 


x=k  A S=seq(V,head,tail-l ) 


and  then 

wp(y-deq(q),  x=k  a S=seq(V,head,tail-l ))  = 

tail>head  A V[head  mod  m]=k  a S=seq(V,head  + 1 ,t ail- 1 ) = 
tail-head>0  a k~S=seq(V,head,tail-l ) = 
length(q)>0  a p./(q)=k~S  = 
r^(q)  = k-S 

For  first  we  must  prove 

e.^(q)=k'-S  ^ wp{x‘-first{q),  6^(q)=k'-S  A x=k) 
The  post-condition  expands  to 

x=k  A k~S=seq(V, head, tail- 1 ) 


and  then 

wp(x*-f irsKq),  x=k  A k~S=seo(V,head,t ail- 1 ))  = 

tail>head  a V[head  mod  m]=k  a k~S==seq(V, head, tail-1 ) = 
(=V(q)=k~S 


2.3.  On  the  Correctness  of  Formal  Specifications 

Now  that  we  have  seen  how  we  can  specify  a module  (data  type)  and  verify  a given 
implementation,  we  come  to  the  question  of  what  we  can  say  about  the  correctness  of  the 
specifications  themselves. 

The  process  of  formal  specification  involves  both  a decision  as  to  the  abstract 
representation  of  an  object  and  decisions  as  to  the  ways  in  which  that  representation  may 
be  perturbed  (by  the  operations  of  the  type).  These  perturbations  are  usually  subject  to 
constraints  which  are  not  fully  described  by  the  choice  of  representation.  For  example,  a 
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r-equence  of  elements  of  type  t may  be  constrained  so  tnat  the  ordering  of  its  elements 
satisfies  some  property  n,  i.e. 

type  seq2  » 

abstract  representation:  sequence(t)  such  that  (YS<seq2)  fl(S) 

This  constraint  on  the  abstract  representation  is  highly  analogous  to  the  constraint  irriposed 
on  a concrete  representation  by  the  invariant  which  describes  the  domain  of  , and  it  has 
been  called  the  abstract  invariant  of  a data  type  [Wulf  76],  What  is  missing  from  that 
treatment  is  a discussion  of  the  relationship  between  the  abstract  invariant  and  the  abstract 
specifications.  While  there  is  no  way  to  guarantee  that  the  specifications  are  "correct"  with 
respect  to  the  highly  abstract  mode!  possessed  by  the  human  who  constructed  them, 
nevertheless  we  can  go  a long  way  by  establishing  that  the  operations  maintain  the 
consistency  of  the  abstract  representation.  The  problem  then  is,  given  an  abstract  invariant 
for  type  t,  ,;/g,  and  a set  of  formal  specifications  of  the  form 

to  establish  that  each  sucn  specification  satisfies 

h ^ h 

Actually,  we  must  be  careful  in  our  treatment  of  free  variables  in  the  various  predicates.  In 
particular,  it  is  dear  that  the  assertion 


V=Vq 

IS  not  invariant  across  the  operation  specified  by 


v=Vq-1  {op}  V=Vq 

and  yet  the  conjunction  (v=Vq)  a (v=Vq-1)  is  false,  and 

false  {op}  Q 

is  always  true.  We  solve  this  problem  by  restricting  the  free  variables  of  J^.  Let  x be  the 
list  of  variables  free  in  P,  Q which  may  have  different  values  in  Q than  they  have  in  P.  These 
are  the  parameters  of  op.  must  contain  no  free  variables  which  are  not  contained  in  x. 
The  tasK  then  is  to  derive 

{op(x)}  ./g 


1 
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from 


P {op(x)}  Q 

Ui.ing  the  Adaptation  and  Consequence  rules  of  [Hoare  71b],  we  can  specify  the  conditions 
which  will  allow  this  inference.  Specifically,  let  k be  the  list  of  variables  free  in  P,  Q but  not 
m X.  Then  frorri  the  rule  of  Adaptation: 


h P {op(x)}  Q 


1-  3MP  A Vx(Q=>,?3))  {op(x)}  Jg 


and  the  rule  of  Consequence; 


I-  P {op(x)}  0,  I-  R^P 


I-  R (op(x)}  0 


we  obtain  the  rule  of  Invariance: 

I-  P (op{x)}  Q,  I-  ./g  A P jk(P  A Vx(Q=»Jg)) 

I-  ^ P Ja 

As  a brief  example,  consider  the  specification  of  a simple  type  for  positive  integers: 
type  posint  = 

abstract  representation  = integer  such  that  (Vz<posint)z>0 

Operations 

Let  q,  r,  s:  posint. 

1)  r=a  A s=b  (plus(q,r,s)}  r=a  a s=b  A q = a+b 

2)  r = a A s=b  A a>b  {minus(q,r,s)}  r=a  A s=b  A q=a-b 
endtype 

Here  is  the  predicate  (Vzf posint)z>0.  To  verify  that  the  specifications  leave  invariant, 
we  must  prove 


(Vz(posint)z>0  A r=a  a s=b  {plus^q.r.s)}  (Vz<posint)z>0 


and 


(Vz''posint)z>0  A r=a  a s=b  a a>b  {minu5(q,r,s))  (Vz<’posint)z>0 

From  the  rule  of  Invariance,  we  must  therefore  show 

(Vz(posint)z^O  A r = a a s^b 
=»  (3a,b)[r  = a a s=b  a 

(Vq,r,s(posint)[r=a  A s=b  a q = a+b  =*  (Vz<posint)z>0]] 

and 

(Vz< posint)z>0  A r=a  a s=b  a a>b 
=»  (3a,b)[r  = a a s=b  a a>b  a 

(Vq,r,s<posint)[r  = a a s=b  a q = a-b  =>  (Vzf  posint)z>0]] 


Both  Implications  follow  trivially. 


3.  Application 


3.1.  Introduction 

The  methodology  of  Chapter  2 is  applicable  to  any  large,  properly  decomposed 
program.  As  we  discussed  in  Chapter  1,  we  are  primarily  interested  in  the  verification  of 
operating  systems.  In  this  chapter  we  shall  present  the  design,  specification,  implementation, 
and  verification  of  a low-level  operating  system  module,  the  process  dispatcher.  A great 
deal  of  emphasis  is  placed  upon  verification  of  the  design  (specifications)  before  verification 
of  the  implementation.  Before  we  attempt  this  tasK  however,  we  must  first  consider  some  of 
the  more  global  aspects  of  applying  the  methodology  to  operating  systems.  In  the  nevt  few 
sections  we  examine  the  effect  of  structure  and  decomposition  on  the  verifiability  of 
eperating  systems.  We  also  consider  the  important  interaction  between  the  language  in 
wh'ich  an  operating  system  is  wrdten  and  the  system  itself. 


3.2.  On  the  Structure  of  An  Operating  System 

The  study  of  operating  systems  design  was  significantly  influenced  by  th'-ee  research 
efforts  - the  T.H.E.  system  of  Dijkstra  [DijKstra  53],  the  RC^OOO  system  of  Bnnch  Hansen 
[Brincti  Hansen  70],  and  the  Muitics  system  developed  at  MIT’s  project  MAC 
[Organic^  72].  The  reason  these  systems  have  been  so  influential  is  the  significant 
contribution  each  lias  m.ade  with  regard  to  the  structure  of  Operating  systems.  The  primary 
reason  for  the  corr'plexity  of  most  commercial  systems  is  not  merely  their  huge  size,  hut  the 
fact  that  fhe  com.plexity  of  a large-scale  system  is  increased  many  times  by  the  lack  of  a 
coherent,  well-modularized  structure.  Since  it  is  our  goal  to  reduce  the  complexity  of 
verifying  operating  systems,  a good  system  structure  is  crucial. 

The  T.H.E.  system  (and  later  the  Venus  system  [Liskov  72])  divided  the  various 
aspects  of  an  operating  system  into  several  Layers  (or  levels),  which  were  arranged  in  a 
hierarchical  manner.  Each  layer  constituted  a modification  of  fhe  next  lower  one,  and  in  this 
way  the  hardware  was  successively  molded  into  a miachine  which  was  much  more  convenient 
to  use.  Each  of  the  layers  (above  the  definition  of  processes)  was  composed  of  a nuniber  of 
processes.  Each  process  could  ask  a lower-level  (but  never  a higtier-level)  process  to  do 
some  work  for  it. 

The  RC^OOO  system  introduced  the  kernel  or  nucleus  approach  to  system  structuring. 
Tills  basic  approach  has  since  been  used  m several  diverse  systems,  including  the  HYDRA 
multiprocessing  system  [Wulf  74].  The  kernel  of  an  operating  system  consists  of  the 
definition  and  managcm.ent  of  primitive  system  features,  including  processes,  memory 
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management,  and  low-level  I/O  This  approach  is  intended  to  allow  for  the  design  of  various 
outer  shells,  all  using  the  same  kernel,  thus  permitting  the  tailoring  of  systems  for  particular 
applications  while  maintaining  a common  basis.  The  kernel  is  typically  the  most  protected 
part  of  the  system,  and  the  approach  has  been  used  to  restrict  the  scope  of  verification  of 
protection  mechanisms  [Schroeder  75].  The  RC4000  system  was  designed  for  use  with 
process  control  computers  having  diverse  applications. 

The  Multics  system  introduced  the  idea  of  a highly  modular  and  distributed  system, 
with  a protection  structure  that  allows  the  dynamic  replacement  of  system  modules  on  a per- 
user basis.  The  distributed,  non-hierarchical  nature  of  the  Multics  system  negatively  affects 
its  verifiability.  In  a non-hierarchical  system,  it  becomes  difficult  to  maintain  the  principle  of 
maximal  encapsulation,  since  each  system  module  has  the  potential  to  call  or  be  called  by  any 
other,  introducing  the  possibility  of  indirect  recursion. 

Kernel  systems  are  not  fundamentally  different  from  layered  systems;  it  is  simply  that 
the  Kernel  boundary  has  special  properties.  A layered  structure  has  the  advantage  of 
restricting  the  scope  of  verification  by  eliminating  cycles  and  recursion,  so  we  shall  want  our 
operating  system  to  be  so  constructed. 


3.3.  On  Hierarchy 

In  [Parnas  74],  Parnas  points  Out  that  there  are  many  possible  hierarchical 
structures,  and  that  any  particular  one  is  not  defined  until  the  parts  (entities  to  be  ordered) 
and  the  relation  (that  governs  the  hierarchy)  are  specified.  The  T.H.E.  system  was  a 
hierarchy  of  abstract  machines  which  consisted  of  processes,  and  the  ordering  relation  was 
"gives  work  to."  The  Multics  system  is  organized  into  modules,  and  there  exists  an  ordering 
relation  wtiich  is  "more  privileged  than",  although  the  hierarchy  is  not  enforced  on  inter- 
niOdule  calls.  The  scheme  we  will  use  is  most  similar  to  that  of  the  Family  of  Operating 
Systems  (FAMOS)  design  project  at  CMU  [Habermann  76].  The  FAMOS  system  is  organized 
in  a layered  manner,  but  the  parts  among  which  the  hierarchy  is  enforced  are  subroutines, 
not  modules  nor  processes.  In  that  system,  a module  is  allowed  to  be  split  among  several 
( levels,  some  of  its  functions  residing  at  each  level.  The  FAMOS  design  strategy  may  be  more 

, general  than  is  necessary,  and  we  hope  we  will  not  find  it  necessary  to  have  modules  cross 

level  boundaries.  This  is  chiefly  because  our  modules  (abstract  data  types)  are  small.  The 
splitting  of  O'Odules  complicates  the  verification  of  invariants,  since  it  becomes  possible  to 
I transfer  from  one  level  of  a module  to  a lower  one  via  an  arbitrary  path,  without  first  having 

, placed  tlie  data  structure  in  a consistent  slate. 

•t 

f 

if 
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3.4.  On  a Decomposition  into  Levels 

Having  decided  upon  the  structuring  technique,  the  decisions  as  to  which  functions 
belong  at  which  levels  becomes  most  im.portant.  A goal  of  the  FAMOS  system  is  that  the 
several  special  purpose  systems  which  are  created  for  a particular  machine  have  as  much  in 
common  as  possible.  This  is  accomplished  by  designing  the  lower  system  levels  so  as  to 
postpone  decisions  which  are  not  sufficiently  common  to  system  family  members.  This  leads 
to  a rather  pleasing  logical  structure.  We  present  a hypothetical  structure  here  which  differs 
from  that  of  the  common  levels  of  the  FAMOS  system  primarily  in  the  ordering  of  processes 
and  M management^.  It  is: 


level  function 

user  interface 
file  system 
user  peripherals 
swapping 

I/O 

Mj.  management 
Mp  management 
synchronization 
processes  and  management 
hardware 

In  the  structure  as  shown,  the  criterion  for  placing  one  level  above  another  is  sim.ply 
that  the  lower  level  has  no  need  for  the  facilities  of  the  higher  one.  Level  1 is  responsible 
for  the  maintenance  of  a fixed  number  of  processes  and  for  the  multiplexing  of  ready 
processes  among  the  hardware  processors.  Above  this  level,  the  actual  number  of 
processors  is  unknown.  Level  2 will  define  the  synchronization  mechanism  to  be  used  by 
processes  (e.g.  semaphores). 

Tlie  next  level,  Mp  management,  is  responsible  for  the  allocation  and  deallocation  of 
priniary  memory.  This  level  is  placed  above  that  of  synchronization  because  it  may  be  that  a 


level  3 

9 

8 

7 

6 

5 

a 

3 

2 

1 
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TSe  Pr.^3  nolalion  of  [Bell  71]  M (pnfnary  memory),  (secondary  memory),  (cen(ral  processor) 


request  for  memory  allocation  cannot  be  satisfiecf  at  a particular  time,  and  the  requesting 
process  must  therefore  be  delayed  until  some  allocated  storage  is  freed. 

A small  digression  is  in  order  at  this  point.  The  FAMOS  system  assigns  the 
responsibility  for  Mp  management  to  a level  below  tnat  of  the  definition  of  processes  - in 
fact  to  the  lowest  software  level.  This  was  done  because  the  lowest  level,  the  one  which 
allocates  memory,  also  introduces  the  concept  of  "protected  addressing  environment",  and  it 
was  felt  that  as  much  of  the  system  as  possible  (i.e.  everything  but  the  lowest  level)  should 
be  so  protected.  The  memory  overflow  problem  (i.e.  running  out  of  memory)  is  solved  by 
using  the  general  mechanism  of  the  software  trap,  which  is  intended  to  model  the  behavior  of 
the  hardware  trao  facility.  Using  this  mechanism,  a level  which  encounters  a condition  which 
it  is  not  prepared  to  handle  can  invoke  a particular  trap,  allowing  a higher,  "smarter"  level  to 
fix  the  problem.  It  is  claimed  that  an  upward  transfer  of  control,  such  as  a trap,  is  not  a 
violation  of  the  hierarchy  if  there  is  no  dependence,  on  the  part  of  the  trap  initiator,  on  the 
successful  result  of  that  trap.  While  this  appears  to  be  true  in  principle,  the  fact  is  that  the 
trap  usually  occurs  in  an  "intermediate"  state,  requiring  that  control  eventually  return  to  the 
point  at  which  the  trap  occurred  in  order  to  continue  the  original  task.  We  (the  author)  feel 
that  such  dependent  traps  are  to  be  avoided.  Since  we  are  not  using  the  addressing 
environment  scheme  in  any  case,  there  is  no  reason  to  place  memory  m.anagement  below 
processes  and  synchronization. 

Returning  to  the  explanation  of  our  hypothetical  system  structure,  level  4 is  assigned 
the  task  of  allocation  and  deallocation  of  secondary  storage,  e.g.  disk,  from  tables  kept  in  Mp. 
Level  5 is  then  in  charge  of  transferring  data  between  primary  and  secondary  memory.  The 
swapping  system,  at  level  6,  uses  the  facilities  of  levels  4 and  5 to  multiplex  the  allocated 
processes  in  primary  memory  (essentially  scheduling  them  in  a much  coarser  fashion  that  that 
of  level  1).  Above  that,  level  7 will  define  access  to  the  other  peripherals  in  the  system  (e.g. 
line  printer,  terminals,  magnetic  tape,  and  card  reader).  Level  8 provides  a file  system  for 
storing  and  retrieving  temporary  or  permanent  data  from  (he  peripherals.  The  user  interface 
at  level  9 then  interacts  with  terminals  to  drive  the  rest  of  the  operating  system. 


3.5.  System  Structure  and  Implementation  Language 

W'e  sketched,  in  Chapter  2,  a programming  language  that  is  strongly  typed  - i.e.  every 
variable  has  a type,  the  type  determines  the  legal  operations  which  may  be  applied  to  that 
variable,  and  there  are  no  implicit  coercions  between  types.  These  attributes  will  greatly 
enhance  the  verifiability  of  programs.  Unfortunately,  we  cannot  define  and  implement  that 
language,  and  then  use  that  fixed  language  throughout  system  implementation,  for  the  simple 
reason  that  the  semantics  of  many  language  features  are  dependent  upon  the  correct 
operation  of  the  system  itself.  For  example,  it  would  not  be  proper  to  use  a language  with 


dynamic  storage  allocation  facilities  In  order  to  implement  any  level  below  that  of 
management,  and  it  would  not  be  proper  to  use  any  built-in  synchronization  constructs  at  or 
below  the  level  at  which  synchronization  is  defined. 

We  therefore  adopt  the  notion  that  the  implementation  language  is  a changing  entity. 
Each  time  a new  level  is  implemented,  that  level  affects  the  language  that  is  to  be  used  to 
implement  the  next  level.  The  easiest  and  most  common  change  that  can  occur  is  the  simple 
introduction  of  new  data  types.  Occasionally,  the  syntax  and  semantics  of  the  language  will 
change. 

The  base  language,  i.e.  the  one  which  we  v^ill  use  to  implement  processes,  will  be 
strongly  typed,  but  contain  no  dynamic  allocation  facilities,  no  recursion,  no  process  creation, 
and  no  synchronization  constructs.  The  only  data  types  in  existence  at  this  point  are  the 
primitive  ones  - integer,  boolean,  and  real.  When  processes  are  implemented,  we  will  add  to 
the  language  the  construct 


cobegin  Sj//  S2//  ■ • .S^,  coend 

which  defines  n processes,  with  process  i executing  statement  Sj.  The  const ruct  will  be 
iiiiplemented  by  choosing  n of  the  processes  made  available  by  level  1 and  assigning  them  to 
the  soecified  tasks. 

Whatever  synchronization  miechamsm  is  introduced  by  level  2,  that  mechanism  will  be 
a''ailatale  for  the  implementation  of  level  3.  One  possibility  might  be  the  conditional  critical 
region  [Brinch  Hansen  73],  another  the  monitor  concept  [Hoare  and  a third  might  be 

path  expressions  [Flon  76].  Each  will  change  the  implementation  language  in  its  own  way. 

When  the  Mp  management  level  is  implemented,  we  will  extend  the  language  to  offer 
dynamic  storage  allocation.  Two  operators,  new  and  free  are  introduced  [Flon  75].  These 
will  be  used  to  allocate  and  release  an  instance  of  a given  data  type,  but  only  from  inside  the 
type  definition.  Creation  of  new  objects  from  outside  the  type  definition  must  be  done  via 
the  create  operation  of  that  type,  which  can  invoke  new  and  free.  This  will  allow  us  to  easily 
verify  proper  initialization  of  all  objects. 

We  imagine  that  level  4 (M^  management)  will  provide  the  language  with  a new  data 
type,  Msblock(size),  to  correspond  to  a block  of  secondary  memory.  Level  5 {M^.  I/O)  will 
provide  operations  to  transfer  fvlsblock’s  between  and  Mp.  Level  7,  the  file  system, 
introduces  the  data  type  file,  with  its  operations  open,  close,  read,  write,  etc.  Further 
extension  of  the  language  by  the  other  levels  is  minimal. 

We  also  emphasize  that  it  is  possible  (necessary,  in  fact)  to  remove  features  and  data 
types  from  the  language  as  they  become  too  primitive,  ihis  will  enable  us  to  reduce  the 
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scope  of  verifications.  For  evample,  the  type  Msbiock  will  not  be  useful  above  the  file 
system,  and  it  would  be  dangerous  to  leave  it  around. 


3.S.  Design  of  the  Process  Level 

Before  presenting  formal  specifications  for  the  process  level  of  our  system,  let  us 
consider  the  criteria  we  would  like  those  specifications  to  satisfy.  First,  the  process  level  is 
intended  to  hide  from  higher  levels  the  actual  number  of  hardware  processors.  This  is 
accomplished  by  defining  a process  to  represent  the  state  of  a particular  computation.  That 
IS,  it  consists  of  a program,  including  global  data  and  constants,  and  local  data  which,  among 
other  things,  contain  the  necessary  Information  for  restarting  that  computation  from  the  point 
at  which  it  was  last  preempted.  It  is  then  possible  to  multiplex  the  processes  aniong  the  real 
processors,  switching  among  the  different  processes  from  time  to  time  in  order  to  g've  the 
appearance  of  continuous  service  to  higher  levels.  A reasonable  goal  is  that  the  processor 
multiplexing  be  done  in  a fair  mianner  (we  shall  be  more  precise  about  the  meaning  of  fair 
later  on). 

Since  processes  actually  in  execution  have  no  useful  task  to  perform  from  time  to  time, 
as  when  they  arc  waiting  for  information  from  another  source,  we  would  (ike  to  separate  the 
set  of  existing  processes  into  those  which  can  execute  and  those  -which  are  v/aiting.  In  fact, 
we  will  define  three  states  for  a process  - waiting,  ready,  and  running.  A waiting  process  is 
not  considered  a candidate  for  assignment  to  a processor  - the  set  of  ready  processes  is  the 
one  from  which  such  candidates  are  chosen.  A process  in  actual  execution  on  a processor  is 
said  to  be  running.  The  three  states  are  mutually  exclusive,  and  as  our  second  goal  we 
vk'Ould  like  to  guarantee  that  every  process  is  in  one  of  the  three  states,  with  corresponding 
implications,  at  ail  times.  As  an  example  of  such  implications,  non-running  processes  must 
have  their  execution  state  saved.  We  will  therefore  restrict  the  transition  to  the  waiting 
state  to  be  made  only  by  the  operation  unready,  and  that  to  the  ready  state  only  by  the 
operation  ready.  In  order  that  we  may  guarantee  a degree  of  fairness  in  the  scheduling,  we 
shall  not  allow  higher  levels  to  choose  which  processes  to  run  next  (else  the  fairness  proof 
could  not  be  localized  to  the  process  level),  although  we  will  allow  them  to  determine  the 
scheduling  points.  For  this  we  define  the  operation  preempt.  We  defer  the  concept  of  "time- 
slice"  to  a higher  level  in  order  to  avoid  the  quite  separable  problems  of  managing  a 
hardware  clock.  We  only  require  of  preempt  that  it  be  called  periodically.  Determination  of 
the  particular  period,  or  even  if  there  should  be  (just)  one,  is  something  to  be  decided  by 
subsequent  performance  evaluation. 

Since  we  desire  a somewhat  realistic  system,  we  will  incorporate  the  notion  of  process 
priority  in  Our  design.  With  each  process  we  associate  a priority.  A process  will  not  be  run 
when  there  are  ready  processes  of  higher  priority.  The  priority  of  a given  process  is 
controlled  by  higher  levels,  but  it  must  remain  fixed  while  that  process  is  ready. 
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3.7.  Formal  Specification  of  the  Goals 

In  this  section  we  present  a set  of  specifications  which  satisfy  the  above  goals.  We 
st'Ongly  suggest  that  the  reader  be  familiar  with  the  notation  and  definitions  of  Appendix  B 
before  proceeding. 

Let  the  abstract  representation  of  a process  be  the  record 

(state:(runriing,  waiting,  ready),  pcs:Pcstate,  prty.mfeger,  lcaded;i>oo/eari) 

wl-iere  Restate  is  a machine  dependent  type  whose  representation  is  suitable  for  saving  the 
si'.arcrt  execution  stale  (e.g.  program  counter,  relocation  registers,  general  registers,  etc.), 
and  wnich  provides  the  operations  unload  and  load  to  save  and  restore  that  state. 

Henceforth  we  will  assume  that  there  is  only  one  hardware  processor  available,  so  that 
load  and  unload  refer  to  that  processor.  Although  we  could  have  assumed  a larger  number 
of  real  processors,  the  resulting  complexity  would  serve  no  pedagogic  purpose.  We  also 
assuine  that  our  processor  has  two  protection  states,  and  that  the  system  (at  least  this  level) 
executes  in  the  privileged  one  while  processes  do  not.  Specifically,  load  and  unload  have 
effect  only  upon  the  "user"  environment. 

Let  the  variable  current  refer  to  the  currently  running  process  (i.e.  current  is  a 
reference^  to  type  process).  Then  we  desire  that  the  operations  at  this  level  {ready, 
unready,  and  preempt)  satisfy  the  invariant 

jtjfcurrent)  = (VpCprocess)  [{p.5tate=ready  =>  p.prty  < current T.prty) 

A (p.state=runnlng  = (p. loaded  a current=lp)] 

A currentT.state=running 

In  order  to  satisfy  this  invariant,  the  decision  as  to  which  process  to  run  next  must  be 
made  by  choosing  a ready  process  of  highest  priority.  In  addition,  in  order  to  provide  the 
fairness  we  discussed  earlier,  we  will  choose  from  the  set  of  such  candidates  the  one  which 
has  been  ready  the  longest.  Since  the  specification  technique  has  no  explicit  notion,  of  time, 
we  must  group  the  ready  processes  in  an  abstract  data  structure  which  m.ahes  that  choice 
convenient.  We  choose  a vector  of  sequences  of  processes  for  this  purpose,  with  each 
element  of  the  vector  representing  the  processes  at  a given  priority,  and  with  the  head  of 
each  sequence  being  the  next  process  to  run  at  that  priority. 


Wo  use  IHo  PASCAL  notation  rT  means  r cef efef enced,  Tf  means  a re^eronco  io  fhe  ob/ect  t 
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Let  R[l..nprty]  be  the  "ready-list"  vector,  with  R[k]  having  type  sequence  of  process. 
Then  ready,  unready,  and  preempt  must  also  satisfy  the  invariant 

l..nprty) 

[(Vp(process)  (has(R[k],p)  s (p.prty=k  a p.state=ready)) 

A (a{plhas(R[k],p)j  =•  length(R[k]))] 

so  that  each  sequence  contains  all  ready  processes  of  a given  priority,  and  that  no  process 
appears  more  than  once. 

We  can  now  attempt  to  properly  specify  the  ready,  unready,  and  preempt  operations. 

1)  rendy(p):  Readying  a process  of  lower  priority  than  the  current  one. 
pre^:  p.state=waiting  a currentT.prty^p.prty  a R[p.prtyj=S 
post:  p=<p', state, ready>  a current=current’  A R[p.prty ]=S~p 


2)  ready(p):  Readying  a process  of  higher  priority  than  the  current  one. 

pre:  p.state=waiting  a current=tc  a c.prty<p.prty  a R[c.prty]=S 

post:  current=Tp  A p=<<p’,state,running>, loaded, true> 

A c=«c’, state, ready>,loaded,false>  a R[c.prty]=S~c 


3)  unready(.p):  Unreadying  a process  other  than  the  current  one. 
pre:  p.state=ready  a R[p.priy]=S~p~V 

post:  p=<p’, state, waiting>  a R[p  prty]=S~V  a current  =current’ 


In  (he  form  discussed  for  specificstion  in  Chap'er  2,  (his  would  read  pre  [read/tp);  past 


30 


4)  unrcadyip):  Unread/ing  the  current  process. 

pre\  current=Tp  a k={>j)(R[j]'r>')  a R[K]=C''S 

post'.  p=<<p’, state, waiting>, loaded, false>  a current^Tc 

A c=<<c', state, running>, loaded, true>  a R[c.prty]='S 


5)  prcemptO:  Pre-empting  with  no  ready  process  of  equal  priority 
to  the  current  ore. 

pro:  (>j)(R[j]?^X)  currentT.prty 

post:  current  =current’ 


6)  pr  eempti):  Pre-empting  while  a process  of  equal  priority  to  the 
current  one  is  ready. 

prc-.  current=Tc  A p.prty  =c.prty  A R[p.prty]=p~3 

post:  current='tp  a p=«p’, state, running>, loaded, true> 

A c=<<c’, state, ready>, loaded, false>  a R[p.prty ]=S~c 

'iote  that  each  of  the  above  specified  process  operations  happens  to  have  two  axioms 
.■>'.r.ociated  with  it.  The  two  axioms  arc  simiply  a convenient  form  of  expressing  the  fact  that 
th.  --e  are  two  basic  choices  as  to  the  outcome  of  the  operation,  and  strongly  suggest  an 
Outer-level  control  sirctcture  of  the  form 

il  Pj  then  Sj  el_sil  P2  Ltl-Q  ^2  else  ermj^  f| 

/vhcre  Pj  {Sj}  Qj  and  P2  {52}  O2  correspond  to  the  two  axioms. 


3.8. 


Verification  of  the  Goals 
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3 8 1 Verification  of  the  Consistency  Invariants 

Before  even  considering  an  irnpfementafion  for  the  specifications  of  type  process,  we 
must  verify  that  these  specifications  satisfy  our  goals.  In  particular,  we  shall  prove  that  both 
J and  J2  S'"®  invariant  across  each  axiom.  The  method  used  to  prove  this  Invariance  is 
given  in  section  2.3.  That  is,  to  show  j is  invariant  over  op(x)  when 

P (op(x)}  Q 


is  known,  we  must  prove 


A P =>  3k(P  A Vx(Q^J)) 

where  X is  the  parameter  list,  and  k is  the  list  of  variables  free  in  P,Q  but  not  in  x.  In  the 
case  where  k is  empty,  we  can  simplify  this  to 

i A P =>  Vx(Q=i^) 

The  proof  follows: 

1)  rcaay(p):  VVe  must  prove 


,^j(current)  a ^ p.state=waiting  a currentT.prty>p.prty  a R[p.prty]=S 

=>  (VqCprocess)  (VTcL.nprty  of  sequence  of  process) 

[q=<p, state, ready>  A current  =current’  A T[q.prty]=S~q 

=»  J j(current)  A 

In  this  case,  as  in  all  of  those  that  follow,  the  truth  of  the  above  expression  can  be 
ascertained  by  straightforward  simplification,  which  we  omit. 
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2)  rcady(p):  We  must  prove 

,;t2(current)  A ^2^^)  ^ p.state^waiting  a current=Tc  a c.prty<p.prty  a R[c.prty]=S 

(Vq.r.curCprocess)  (VKl  .nprty  of  sequence  of  process) 

[(cur  = Tq  A q=<<p, state, running>,loacieci,true> 

A r=«c, state, ready>, loaded, false'>  a T[r.prty]=S~r) 

=>  il(cur)  A ^2(T)] 


3)  unrcadyip):  Vw'e  must  prove 

/jfcurrent)  A J 2^^'^  ^ p.st ate ^ready  a R[p.prty]=S~P”V 

-■»  (Vq*  process)  (VT*  I..nprty  cf  sequence  of  process) 

[q  = <p,‘'-tate,vvaiting>  a T[q.prty ]=S~V  a current=current’ 


j(current)  A ^2^'^] 


^)  unr»‘o.d yip):  W'e  must  prove 


I 

I 

I 


) 


J ^(current)  A j 2^^'^  ^ current=Tp  a k=(>j)(R[j]i^X)  A R[K]=c~S 

(Vq,r,curr process)  (VTcL.nprty  of  sequence  of  process) 
[(q=<<p, state, waiting>, loaded, faise>  a cur=1r 

A r=<<c, state, running>, loaded, true>  a T[r.prty]=S) 

j(cur)  A ^2^'^^)] 


5)  i>iccmptO:  We  must  prove 


,^j(current)  a J 2^^~>  ^ (>j)(R[j]»^X)  < currenti.prty 
^ (current  =current’ 


=■*  J j(current)  A J 2^^^^ 
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6)  preempti):  We  must  prove 

j/^(current)  a ^2^^^  ^ current=Tc  a p.prty=c.prty  A R[p.prfy]=p~S 

=»  (Vq.r.curfprocess)  (VT(l..nprty  of  sequence  of  process) 

[{cur=Tq  a q=<<p, state, running>, loaded, true> 

A r=«c,state, ready>, loaded, false>  a T[q.prty ]=S~r) 

=»  J^(cur)  A 

This  completes  the  proof  that  both  and  J2  invariant  across  the  operations  of  the 
process  module. 

3.8  2 Verification  of  the  Fairness  Property 

We  vw'ill  now  attempt  to  prove  that  any  implementation  of  the  specifications  for  type 
process  satisfies  the  fair  service  goal.  In  particular,  we  shall  prove  that  the  ready  processes 
of  liighest  priority  are  executed  in  Round  Robin  fashion.  Although  there  may  be  many 
alternative  definitions  which  may  have  their  own  merits,  this  one  is  reasonable  both  from  the 
context  of  system  behavior  we  possess  thus  far,  and  for  the  pedagogic  purpose  of 
illustrating  the  verification  technique.  Karp  and  Luckham  [Karp  76]  have  verified  a fairness 
property  for  a particular  implementation  of  a process  dispatcher.  The  proof  we  shall 
present,  dealing  with  the  specifications  only,  applies  to  any  arbitrary  implementation. 

The  proof  takes  the  form  of  induction  on  the  history  of  calls  upon  the  operations 
ready,  unready,  and  p’-eempt-  VJe  shall  require  the  addition  of  an  auxiliary  variable  to  the 
specifications,  for  the  purpose  of  recording  the  successive  values  of  the  pointer  current. 
This  varioole  is  denoted  H,  and  will  have  type  sequence  of  process.  It  is  initially  equal  to  the 
null  sequence.  Whenever  a specification  of  the  form 

current-Tp  a pj^c  [op]  current'Tc 

IS  c>.  ‘ ; «. ! er'e--er  current  is  changed  across  op),  we  will  replace  it  by 

turrenf“Tp  A A H=S  {op}  current  = Tc  A H=S~c 
The  to  he  pfc  en  can  now  be  cast  as: 

Theorem 
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Let  a and  b be  arbitrary,  distinct  rpady  processes  of  equal  priority,  and  let  there  be 
no  non-waiUng  processes  of  higher  priority.  Then,  for  any  sequence  of  calls  on  ready, 
unready,  and  preempt  which  maintains  this  state,  the  resulting  history  of  dispatching,  H,  when 
reduced  by  deletion  to  a sequence  of  just  a’s  and  6's,  will  be  of  the  form  (ab)*(av\). 


Formally,  let  p(S)  reduce  S to  only  a’s  and  b’s,  i.e. 

p(a)  = a 
pib)  = b 

p(c)  = X if  Ci^a  and  ci^b 
p(S~x)  = p(S)~p(x) 

Then  without  Iocs  of  generality  we  wish  to  prove  the  relation 

JIfg, ,(R,H)  = p(H~R[a.prty])  C (ab)*(avX) 

invariant  over  any  history  v/hich  maintains  the  state 

a.p'-ty  = b prty  a a.state-^waitmg  a b. state-awaiting 
A currentT.prty<a.prty  a a.prty =(>K)(R[k]^X) 


Proof: 

1)  rcady(p):  We  must  prove 


^ J l(current)  A J2(R) 

A p.state«=waiting  a curr entT.prty>p.prty  a R[p.prty]=S 

*»  (Vq<  process)  <VT(  l-.nprty  of  sequence  of  process) 

[q=»<p, state, read/>  a current  =current’  a T[q.prty ]=S~q  a H=H’ 

j(current)  A ^ p(H~T[a.prty])  ( (ab)*(avX)] 

We  can  assume  p/a  and  p.^b  (because  p.state==waiting). 

Furthermore  p.prtySa.prty,  else  afterwards  there  will  be  a higher  priority  non-waiting 
process. 


Then  p(H''T[a.prty])  = p(H'R[a  prty]). 
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2)  ready(p): 

Since  p.prty>currentT.prty,  the  conditions  of  the  theorem  are  violated,  and 
we  need  not  consider  this  case. 

3>  unready{o):  We  must  prove 

A ,?j(current)  a ^ p.state=ready  a R[p.prly]=S~p~V 

(VqCprocess)  (VT(l..nprty  of  sequence  of  process) 

[q=<p, state, waiting>  a T[q.prty]=S'>'V  a current=current’  a H=H' 

=»  ,^j(current)  a J2(T)  a p(H-T[a.prty])  € (ab)*(avX)] 

We  can  assume  that  p^a  and  p^b,  so  p(H~T[?.prty])  = p(H~R[a.prty ]). 


f 
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unreadyip)-.  We  muct  prove 


A j(current)  a ^ current  = Tp  a K=(>j)(R[j]/X)  a R[k]=c~S  a H=V 

(Vq.r.currprocess) 

(VT(l..nprty  of  sequence  of  process)  (VW<sequence  of  process) 

[q=<<p,sf ate, waitmg>, loaded, false>  a cur  = Tr 
A r=<<c,state,running>,loaded,frue>  a T[r.prty]=S  A W=V"-r 

=»  ,^^(cur)  A p(W~T[a.prty])  < (ab)*(avX)] 

We  assume  p^a  A pVb. 

i)  Suppose  c=a.  Then  p(W)=pfV^a)=p(V)~a  and  p(R[a.prty])=a~p(S)=a'-p(T[a.prty]). 
So  p(W~T[a.prty])=p(V)~pfR[a.prty])=p(H-'R[a.prty]). 

ii)  Jf  c=b,  the  symmetric  argument  bolds. 

iii)  If  cya  A cyb,  then  p(W~T[a.prt y])=p(W)~p(T[a.prty]) 

=p(V)'p(R[a.prtyj)=p(ri'~Pfa.prfy]). 
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5)  preernpti):  This  is  trivial. 


6)  preempti):  We  must  prove 


A ^j(current)  a 

A current=»Tc  a p.prty  =c.prty  a Rfp.prty ]=p~S  a H=V 

^ (Vq.r.curf process)  (VT<l..nprty  of  sequence  of  process) 
(VW<sequence  of  process) 

[cur=Tq  A q=<<p, state, runnmg>, loaded, true> 

A r=<<c,state,ready>,loaaed,false^  a T[q.prty]=S~r  A W=V~q 

=>  ,yj(cur)  A ^2^^)  ^ p(W~T[a.prfy])  i (ab)*(avX)] 

i)  Suppose  p=a.  Then  p(H)<(ab)»  and  p(S)=b  or  p(S)=X. 

So  pfW~T[a.prty])=p(H)''a~p(S)'-p(r). 

If  c=b  then  p(S)=X  and  p{W~T[a.prty])=p(H)'-a~b. 

If  Ci^b  then  p(S)=b  and  p(W~T[a.prty])=p(H)~a'-b. 

ii)  The  symmetric  argument  holds  for  p=b. 

ill)  Assume  pi^a  a p^b.  Then  p(W)=p(H). 

If  c=a  then  p(S)=b  and  p(H)((ab)*a,  so  p{W~T[a.prty])  ( (ab)*aba. 
If  c=b  then  p(S)=a  and  p(H)((ab)*,  so  p{W~T[a.prty])  i (ab)*ab. 


So  ,7fair  is  indeed  invariant  for  any  irriplementation  of  the  given  specifications.  Thus, 
we  have  succeeded  n verifying  something  which,  though  conceptually  relatively  simple,  has 
not  been  rigorously  proven  in  the  past. 
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3.9.  Implementation  of  the  Process  Level 

The  specifications  for  type  process  given  in  the  previous  section  rely  on  the 
manipulation  of  the  abstract  data  structure,  R,  v/hich  we  called  the  ready-list  (even  though  it 
isn't  a list).  Therefore,  the  programs  for  type  process  which  iiriplement  those  specifications 
must  eitfier  implement  a concrete  ready-list  modelled  after  R,  or  else  rely  upon  a separate 
m-iplernentation  of  such  a structure.  For  the  moment  we  will  assume  the  latter  course. 

Based  upon  the  manipulation  of  R in  the  specifications,  we  postulate  a new  type, 
multiq,  of  which  the  ready-list  is  an  instance.  Its  specifications  are: 

Abstract  Structure: 

muLt ype,^'\:integer}  = vector  l..nl  of  sequence  of  \ 

Operations: 

1)  append(M:rr.uft;c;,n:  1 ..nl,x:f ):  Appends  x to  M[n]. 
wp(append(M,n,x),  M[n]=S^l'.  a x = k)  = 

M[n]=S  A x=k  A (Vjc  l..nl)-has(M[j],k) 


2)  delete(M:mu(t(g,n:  1 ..nl,x:t):  Deletes  x from  M[n]. 


wp(delete(M,x),  M[n]-V)  = 


V=S~T  A M[n]=S''X~T 


3)  j‘-highest(M:rriu(J((7):  Retu''ns  the  higliest  index  in  M of  a non-null  element. 
wp{j»-highest(M),  j=(>n)(M[n]y\^)  = ' 

(3n)(M[n]y\) 


1/ 
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■3)  rewc-  e' irm/f iq,n:  1 nl):  Returns  the  first  element  of  M[n]  after  removing  it. 
* pi  q*-r  emo  . eCvt.n),  M[n]=S  a » 


M[n]-K'-S 


Mssurning  these  specifications,  we  can  give  the  following  straightforward  implementation  of 
type  process: 

t_y  pe  process  - 

y^ar  pm:  1 nproc; 

own  pvec;  array  [1.. nproc]  of 
record 

state:  (running, waiting, ready), 
pcs:  Restate, 
loaded:  boolean. 
prty:  L.nprty 

end, 

R:  multiqf  1.. nproc, nprty), 
cur;  1.. nproc; 

macro  proc[p]  = pvec[p.pin], 
cproc  = pvec[cur]; 

op  ready(p:process)  * 

d proc[p].state/waiting  then  error 
elsif  cproc. prty>proc[p]. prty  then 
P'"Oc[p].state‘-ready; 
append(R,proc[p].prty,p.pin) 


unload(cproc.pcs);  cproc.loaded<-f  alse; 
cproc.state*-ready; 
append(R,cproc.prty,cur); 
cur*-p.pin; 

cproc.statec-running: 
load(cproc.pcs);  cproc.loaded<-true 


else 


CP  unready(p:process)  = 

if  proc[p].state  = 'A'ai!ing  (lien  qrrqr_ 
elsif  proc[p].state=^ready  ll-.en 
proc[p]s!ate‘-waitmg; 
delete{R,proc[p].prl/,p,p,n) 

else 

unload(cproc.pcs);  cproc.loaded'-f alse; 

cproc.stale'-waiting; 

cur«-remove(R,highesUR)): 

C proc.st  ate ‘-running; 
load(cproc.pcs);  cproc.loaded‘-truc 

li: 


^ preempt  = 

if  highest(R)>cproc.prty  t.‘-ej2 
begin 

\^ar_  p;l..nproc; 

p<-remove(R,cproc.prty ); 

un!oad(cproc.PCs);  cproc.!oaded‘- false; 

cproc.state»-ready; 

append(R,cproc  prty.cur); 

cur<-p; 

cproc.st  ate ‘-running; 
load(cproc.pcs);  cproc.loadcd*-true 
end 
fi 

endty  pe 


3.10.  Verification  of  Type  Process 

The  verification  of  the  implementation  just  presented  follows.  We  define 

pV(cLir)  = current 
nc/fcproc)  = current! 
e!/(p:l..nproc)  ■=  piTprocess 
p^(proc[p])  = piprocess 


maintaining  the  abstractions  of  Restate,  (running, read/, waiting),  and  R.  For  this  case,  the 
woll-defincdness  of  c.4  is  guaranteed  by  static  type  checking.  That  is,  the  fact  that  the 
program  compiles  guarantees  that  it  will  always  be  in  a state  which  is  in  the  domain  of  a;/'. 
We  now  give  the  proo'  of  each  axiom  of  the  specifications  in  turn: 

1)  reQc(y(p):  We  must  prove 

proc[p].state=waiting  A c proc.prty>proc[p].prty  A R[proc[p].prty]=S 

=»  wpfreadyfpJ,  proc[p]=<proc’[p],state,ready>  A cur=cur’  A R[proc[p].prty]=S~p) 
Computing  the  weakest -pre-condition,  we  obtain: 
op  ready(p;process)  = 

{ proc\p]  stale-waiting  n cproc  prty>proc{p'\prty  =»  cur-cur"  A R[proc[p]  prty]-S 
A (V/tl  nprty)-hasi.R[J],p)  } 
d proc[p].5tate?<waiting  then  error 
elsif  cproc. prty>proc[p].prty  then 

( cur-cur"  a R[proc[p]prty]-$  a d J(l  nprty)-has(R[j],p)  } 
proc[p].st  ate ‘-ready, 

[ proc[p]-<proc"[p],slate,ready>  a cur-cur"  a R[prcc[p]prty]-S 
A (VAl  nprty)-hastR[i\p)  ) 
append(R,proc[p].prty,p.pin)-, 
else  . . . 

li; 

{ proc[p]-s.pro<f[p].s1ate,reody>  a cur-cur"  a R[proc[p]  prty]-S~p  ] 


The  weakest  pre-condition  is  implied  by  the  given  pre-condition  and  the  invariant 


2)  rendyip):  We  must  prove 


proc[p]. state-waiting  A cur=c  A proc[c].prty<proc[p].prty  A R[proc[c].prty]=S 

=>  wptreaa'yi'p',  cur  = p a proc[p]=<<proc’[p], state, running>, loaded, true> 

A proc[c]=«proc’[c], state, ready>, loaded, false>  a R[oroc[c].prty ]=S~c) 

Computing  the  weakest-pre-condition,  we  obtain; 

0£  ready(p:p'‘Ocess)  = 

i proc[p]sl.^tc•wJltlnf  A cproc  prty<proc[p]prly  A cor-c  =>  S’[p'-oc[c]  prr)']-S  A (V/tl  nprt /)-has(Rl/].c)  } 
d prOc[p].state;^waiting  t_he£i  c^rO£ 
elsif  cproc.prty>proc[p].prty  . . . 

el_se 

; a/r-p  =»  ‘?LP'Oc[p]  pr^y]-S  A (V;tl  np'-ty)~h3s(R[i].c)  1 
unioadtcproc.pcs);  cproc.loaded'-faise;  cproc.state'-readyj 
j cvr-c  =•  p'cc[c]’<<proc[c), st,ite.re3dy>, leaded, fa!se>  a R[proc[c]  prty]-S 
A (VAl  np'fy)'^Js(ff[/],p)  } 
append(R,cproc.prty,cur);  cur^p.pin; 

{ CJr-p  A proc[c]-<<prod[c].slale,ready>,hoded.fjlse>  a ,<7{proc[c]  prf)  ]-S-c  ) 
cproc.state«-running;  load(cproc.pcs);  cproc.loaded‘-true; 

lu 

{ cur.p  A proc[p]-^<proc[p].stafe,''unninf:>,h3ded,(rve> 

A proc[c]-<<proc'[c], state, ready>, haded, f3lse>  a /T[proc[c] prfy]“S~c  ) 


The  weakest  pre-condition  is  implied  by  the  given  pre-condition  and 
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3)  unready(p):  We  must  prove 

proc[p].state=ready  a R[proc[p].prty]=S'P~V 

=»  '*ip{anready(p),  proc[p]=<proc’[p], state, waiting> 

A R[proc[p].prty]=S~V  A cur=cur’) 

Computir^g  the  weakest-pre-condition,  we  obtain; 

OD  unready(p;process)  = 

( proc[p]sfote-ready  =»  cur-cur  A R[proc[p]  prty]-S~p~V  ) 

[f  proc[p].state  = waiting  then  error 
elsif  proc[p].state=ready  then 

( cur-cur"  a R[proc[p]  priy]-S~p~V  } 
proc[p].state‘-waiting; 

( proc[p]-<proc'[o],sfate,w,vtmg>  a cur-cur"  a R[proc{p]  prty]-S~p~V  } 
deIete(R,proc[p].prty,p.pin) 
else  . . . 
ti; 

( proc[p]-<proc’lp],st3te,w3iting>  a R[proc[p]  prty]-S~V  A cur-cur"  ) 


The  implication  of  the  weakest  pre-condition  is  clear. 


*3)  unreadyip):  We  must  prove 
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cur=p  A k=(>j)(R[j],»!X)  A R[k]=c~S 

=»  wp(uarcac/yi p ),  proc[p]=<^proc’[p], state, '//a. tirg>, loaded, false>  a cur«c 

A proc[c]=<<proc’[c], state, running>, loaded. true>  a P[proc[c].prty]=S) 

Computing  the  weakest-pre-condition,  we  obtain: 

op  unread/(p:process)  = 

1 proc[p]  stalc^wailing  a proc[p]  slafPrlready  A cvr.p  s p'oc[c]  prty(.>  a Piprocfc]  prfy].c-S  ) 

if^  proc[p].state  = waiting  then  ^ro£ 
elsif  proc[p].state=ready  then  , . . 
else 

{ cur-p  =*  proc[c]  pr^)'.(>/■KP[/]/X)  A fT[prcic[c]  pr^>-'].c-S  ) 

unload(cproc,pcs)i  cproc.ioaded'-false;  cproc.state*-waitmg; 

{ proc[p]-<<proc’[p],st3te.w3ifing>,l‘^^d^<^,f3ise> 

A proc[c]prti'^{>j)(R[j]^x)  a /r;prcc[c] prfy]-C'5  ) 

cur<-remove(R,highest(R)): 

{ proc[p]-<<proc'[p],staie.^3dirg>Jcac!ed,'a'se>  a cur-c  A R[proc[c]  prty]-S  ] 
cproc.state'-running;  load(coroc.pcs);  cproc.loaded^-true; 

! p'oc[p]~<<proc’[p], state,w3iling>, leaded, fo^se>  a cur-c 

A proc[c]-<<prpc’[c].sfa?e,n,'nn(np>,/c3t:ec/,frL'e>  a R[proc{c]  prl)']-S  } 


The  jrr.plication  of  the  weakest  pre-condition  is  dear. 


5>  preempt^):  We  must  prove 

(>j)(R[j]?'X)<cproc.prty  \fjp{preempt(),  cur=cur’) 
This  proof  is  trivial. 


Lj 
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6)  preemptO:  We  must  prove 


I 


cur 


A proc[p].prty  = proc[c].prty  A R[proc[p].prty]  = p~S 


'Mp{preempt(\  cur=p  a proc[p]=<<proc'[p], state, running>, loaded, true> 

A proc[c]=<<proc’[c ],state,ready>, loaded, false>  a R[proc[p].prty]=S~c) 

Computing  the  weaKest-pre-condition,  we  obtain: 

op  preempt  = 

{ (>i't(R[j'\^y)>cproc  prty  a fur-c  a cproc  prt  yproc[p]  prty  a 

R\prcc[p]  p’-ty]-p~S  A (V/tl  nprty)~hps(.R{i].c)  } 
i_f  highest(R)>cproc.prty  then 
begin 

var  p:l..nproc; 

! cur-c  A cproc  prtyproc[p]  prly  P[proc[p]  prty]-:p-S  A nprty)-hes{R[j'],c)  J 

P‘-remove(R,cproc.prty); 

( cur-c  » Rlpraclp]prty]-S  a \ ._nprty)-hasiR[f\.c)  ) 

unload(cproc.pcs);  cproc. ioaded<-false;  cproc. st ate«-ready; 

{ curmc  a proc[c]-<<prpc'[c],sfjle,re3dy>, haded, fa'ss>  a R{proc[p]  prty]-S 
A (VA  1 nprty)~has{R[/],c)  } 
dppend(R,cproc.prty,Cur ); 

{ proc[c]-<<proc‘[c].state,ready>.haded,fahe>  a Rlproc[p] prty]-S~c  } 
cur*-p;  cproc. state'-running; 
load(cproc.pcs);  cproc.loaded‘-t rue 
end 
lij 

( cur-p  A proc[p]-<<proc’[p],state,runn<ng>,loaded.true> 

A proc{p]-<<prod[c],stale.ready>,haded,fa!se>  a R[proc[p]  prty]-S-c  ) 


The  weakest  pre-condition  is  implied  by  the  given  pre-condition  and 

3.11.  Implementation  of  Type  Multiq 

In  the  implerrientation  and  verification  of  type  process,  we  relied  upon  the  existence  of 
another  type,  multiq,  with  which  we  impleniented  the  ready-list.  Now  we  come  to  the 
implementation  of  type  multiq,  and  subsequently  its  verification.  Refer  to  the  specifications 
given  in  section  3,9. 
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The  specifications  clearly  allow  a complolcly  separate  implementation  of  type  multiq, 

ancj  a reasonable  approach  would  be  to  construct  such  a type  by  using  a vector  of  list 

✓ 

pointers  as  the  representation,  i.e. 
type  multiott :t ype.nl :mtep,er)  - 
yj^  Hiarrav  [l..nl]  oj_  el; 


enettype 

where  type  el  'S  (valueit,  succ:l..nl). 

While  we  could  construct  such  an  implementation  without  too  much  difficulty,  it  would 
be  rather  inefficient.  Each  process  on  the  ready-list  would  require  two  pointers  (one  to  the 
process  and  one  to  the  next  list  -.lement).  Furthermore,  each  insertion  or  deletion  would 
require  storage  allocation  or  de-allocation  of  the  list  elements. 

If  we  had  been  constructing  our  system  in  a not-so-careful  manner  and  without 
verification  in  mind,  we  would  prooably  have  implemented  the  ready-list  as  a "thread" 
through  the  processes  themselves  - i.e.  we  would  extend  the  representation  of  a process  to 
contain  a pointer  to  other  processes.  With  a little  reflection  we  find,  in  fact,  that  we  can  still 
do  just  that.  We  re-dedare  the  structure  of  type  process  to  be: 

type  process  ■ 

var  pin;  1 ..nproc; 
own  pvec:  array  [1.. nproc]  o^ 
record 

state:  (running, ready, waiting), 

pcs;  Restate, 

loaded:  boolean. 

prty:  l..nprty, 

nert;  L. nproc, 

prev:  I. .nproc 

end, 

R:  array  fU.nprtyJ  q£  Q..nproc, 
cur:  1.. nproc; 


endtype 
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Then  we  can  see  that  the  previous  verification  of  type  process  is  unaffected  (because  we 
deleted  nothing  and  changed  only  the  concrete  t^pe  of  R).  Now  we  can  implement  the 
operations  of  type  multiq  as  local  procedures  of  type  process,  obtaining  both  a reasonable 
verification  task  for  type  multiq,  and  an  efficient  implementation  thereof.  Our  implementation 
follows; 

proc  appendR(l;l..nprty,k:l..nproc)  = 
ij.  R[l]=0  then  R[l]«-k 
else 

swap(proc[k].succ,  proc[proc[R[l]].pred].succ)j 
swap(proc[k].pred,  proc[R[l]].pred) 


proc  removeR(l:l..nprty):l..nproc  = 
begin 

var  K:  L.nproc; 

K-R[l]; 

d k=*0  then  error  else  deleteR(l,k)  fjj 
k 

end; 


proc  deleteR(l:l..nprty,k;l..nproc)  = 

[f  R[l]=k  then 

iX  proc[k].succ=proc[k].pred 
then  R[l]<-0 
else  R[l]<-proc[kj  su;c 
fi 

else 

swap(proc[k]  succ,  proc[p.  Oc[k]  pr edj.succ); 
swap(proc[k].pred,  proc  [proc  [i"  ].succjpred) 
ti: 


prqc  highestR;l..nprty  - 

yAL  k:l..nprty; 
k«-nprty; 

while  R[k]*0  ^ k‘-k'l  o^ 

k 


43 


3.12.  Verification  of  Type  Multiq 

The  concrete  invariant  j of  the  given  multiq  implementation  must  fully  capture  the 
notion  of  a doubly  likened  circular  liit.  The  following  ic  a concise  definition  of  the  concept; 

J -=  (Vj<  l..nproc)(j=proc[proc[)]  succ]  pred  a j=proctproc[j].pred].succ) 

That  IS,  every  process  has  the  property  that  one  step  forwards  (succ)  followed  by  one  step 
backwa''ds  (pred),  or  vice  versa,  will  get  you  back  to  where  you  started  from.  Note  that  this 
must  also  be  true  of  those  processes  which  are  not  on  a list  (they  must  be  self-referencing), 
and  that  is  precisely  what  makes  the  link  swapping  implementation  work. 

Proving  the  above  predicate  invariant  is  a matter  of  applying  the  rules  for  array 
assignment  and  access^  with  appropriate  simplification.  We  illustrate  the  method  by  showing 
j invariant  across  the  appendR  procedure. 

Assume  the  concrete  pre-condition  to  append  R is 

W = proc[k].succ=k  A proc[k].pred=k  a (Vj(  l..nprty)(R[j]yk) 

That  is,  k is  not  a member  of  any  list  yet  (because  the  only  way  to  reach  a self -referencing 
element  is  directly  through  the  list  headers  in  R,  and  this  is  guaranteed  impossible).  Compare 
this  pre-condition  with  the  abstract  weakest  pre-condition  specified  in  section  3.9. 

We  must  show 


W A J ^ wp(appendR(l,k),  J) 

Clearly,  if  R[l]=0  initially  then  R[l]=k  will  satisfy  the  invariant.  The  interesting  case  then  is 
R[l]>0.  Assume  swap  to  have  the  definition 

wp(swap(x,y),  P)  » P|^’^ 

(simultaneous  exchange  of  the  variables  x and  y).  Then 

wp(swap(A[x],A[y]),  A=Aq)  = A=«Aq,  [x],  Ag[y]>,  [y],  Aq[x]> 
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See  Appendix  B 


Thus  if  R[l]>0,  wp(appendR(l,k),  j a proc=P)  - 


proc- 

< < < <P,  [k].pred,  P[R[l]].pred>, 
[R[l]].pred,  P[K].pred>, 
[k].succ,  P[P[R[l]].pred].succ>, 
[P[R[l]].pred].succ,  P[k].succ> 

We  want  to  show 


j=proc[proc[jj.succ].pred  A j=proc[proc[j].pred].succ 


Now  proc[j].succ  = 

if  j=P[R[l]].pred  then  P[k].succ 
elsif  j=k  then  P[P[R[I]]  pred].succ 
else  P[j].succ 

Thus  proc[proc[j].succ].pred  = 

if  proc[j].succ  = R[l]  then  P[k].pred 
elsif  proc[j].succ=k  then  P[R[l]].pred 
else  P[proc[j],succ].pred 

There  are  three  possibilities  for  j: 

1)  Suppose  j = P[R[l]].pred. 

Then  proc[j].succ=»P[k].succ 
and 

proc[proc[j]  succjpred  = 

if  P[k].succ=R[l]  then  P[k].pred 
elsif  P[k].succ=k  then  P[R[l]].pred 
else  P[P[k].succ j.pred 

From  the  pre-condition  W,  v.'e  know  P[k].succ=k  and  R[l]i^k,  so 
proc[proc[j].succ].pred  = P[R[l]].pred  - j 
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2)  Suppose  j=K  A ji^P[R[l]].pred. 

Then  proctj].succ  = P[P[R[l]].pred].succ 
and 

proc[proc[j].succ].pred  = 

if  P[P[R[l]].p''ed].5UCC  = R[l]  then  P[K].pred 
etsif  P[P[R[l]].pred].succ  = K then  P[R[l]].pred 
else  P[P[P[R[l]].pred].succ].pred 

From  J,  we  know  that  P[P[R[I]]  pred].succ  = R[l],  so 

proc[proc[j].succ].pred  = P[k].pred  = K = j 


3)  Suppose  j?<k  A j/P[R[l]]  pred. 

Then  proc[j].succ  = P[j],succ 
and 

proc[proc[j].succ].pred  = 

if  P[j].succ=R[l]  then  P[k].pred 
elsif  P[j].succ=k  then  P[R[l]].pred 
else  P[P[j].succ].pred 

If  P[j].succ=R[i]  then  P[P[j].succ].pred  = j = P[R[l]].pred 
which  contradicts  the  hypotheses. 

Furthermore,  if  P[j].succ=k  then  P[P[j].succ].pred  = j *=  P[k].pred=k 
which  also  contradicts  the  hypotheses.  So 

proc[proc[j].succ].pred  = P[P[j].succ].pred  = j 

Similarly,  we  can  establish 

j“proc[proc[j].pred].succ 

and  we  omit  that  proof.  Using  the  same  ideas  we  can  show  j to  be  invariant  across  all  of 
the  operations,  and  we  omit  those  proofs  also  as  not  useful  to  the  presentation. 

Since  J is  invariant,  the  mapping  from  the  concrete  to  the  abstract,  for  which  we  shall 

use 
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p'-/(R,proc)  = Rg  (the  abstract  object  R used  in  the  specifications) 

Ra[j]  » if  R[j]-0  then  X else  seq(proc,  R[j],  R[j]) 

seq(proc,  X,  y)  - if  proc[x].succ=y  then  proc[x] 

else  proc[x]''seq(proc,  proc[x].succ,  y) 

IS  well-defined.  To  be  rigorous  we  shouid  have  to  prove  that  the  invariant  guarantees 

(3n)  proc[R[l]].succ'^  = R[l] 

(where  Ci-Succ'^  means  q.succ.succ.  . .succ  n times)  but  we  will  take  that  as  obvious.  Under  the 
above  mapping,  the  pre-condition  W becomes 

e^(W)  = (Vjc  l..nprty)-has(Ra[j],k) 

Thus,  for  appendR,  it  only  remains  to  show 

wp(appendR(l,k),  Rg[l]=S-"k)  = Ra[l]=S 

From  the  definition  of  seq,  we  can  deduce  that 

■ proc[k].succ=first(S)  a proc[last(S)].succ=k 

Furthermore, 

first(Rg[j])  = G,/(proc[R[j]]) 

and 

iast(Rg[j])  - c.^(proc[proc[R[j]].pred]) 

(assuming  the  interesting  case  when  R[j]>0).  Thus  we  must  compute 

• wp(appendR(l,k), 

proc[k].succ=R[l]  a proc[procrj[R[j]].pred].succ=k) 

I where  procQ  refers  to  the  state  of  proc  at  entry.  This  works  out  to 

I 

f procQ[k].succ=k  A procQ[procQ[R[l]],pred].succ=R[l] 


which,  in  light  of  the  invariant,  will  map  via  a/  to 
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RaD]  = S 


While  this  proof  has  not  been  as  rigorous  as  it  might  have  been,  it  is  convincing,  and 
there  is  little  to  be  gained  from  formally  proving  all  of  our  assumptions  (such  as  the  obvious 
relationship  between  the  first  and  last  operators  and  cv/.  The  proofs  of  removeR,  deleteR, 
and  highestR  are  straightforwardly  similar  and  are  not  included. 
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4.  Verifying  General  Parallel  Programs 


4.1.  Introduction 

The  verification  formalism  for  sequential  programs  is  relatively  well-understood,  and 
indeed  most  of  the  proof  rules  for  programs  used  in  Chapter  2 are  not  new.  In  dealing  with 
operating  systems  however,  we  are  frequently  faced  with  the  problem  of  verifying  parallel 
programs.  A totally  satisfactory  formalism  for  this  task  has  not  yet  appeared. 

In  this  chapter  we  will  explore  two  approaches  to  parallel  program  verification  for  a 
rather  general  syntactic  class  of  programs.  The  first  (section  fl.2)  uses  DijKstra’s 
weakest  pre-condition  semantics  [Dijkstra  76]  to  statically  consider  all  of  the  possible 
execution  paths  of  a system  of  parallel  processes.  The  second  (section  4,3)  extends 
Owicki’s  methodology  [Cwicki  75]  to  handle  arbitrary  programs,  without  relying  on  a high- 
level  synchronization  mechanism.  A methodology  is  given  for  proving  loop  termination  in 
parallel  programs. 


4.2.  Combinatoric  Weakest  Pre-Condition  Semantics 


4 2.1  Primitive  Actions 

It  is  a well-known  fact  that  because  a single  high-level  language  statement  is  generally 
compiled  into  a sequence  of  machine  instructions,  it  may  be  that  a process  is  interrupted  at  a 
"mathematically  inconvenient"  place.  This  is  reflected  in  the  following  classical  example^; 

{x»0}  ADD2:  cobegin  x»-x  + l //  x*-x-t-l  coend  {x*=l  v x-2] 

In  spite  of  the  fact  that  both  processes  appear  to  increment  the  variable  x,  if  the 
incrementation  is  not  indivisible  the  final  value  of  x will  be  nondeterministic. 

The  difficulty  m proving  the  correctness  of  such  programs  lies  primarily  in  the  fact 
that  the  primitive  decomposition  of  ”x‘-x  + l"  is  not  lexically  exphcd.  In  order  to  be  able  to 
prove  such  programs,  it  is  necessary  that  the  semantics  of  higher-level  language  statements 
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coend  b^ock  defin»t  ird«vidual  to  b«  B»*»cut«»d  by 


process 
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include  enough  information  to  allow  determination  of  the  possible  pre-emption  points.  For 
the  case  of  simple  incrementation,  the  definition 

wp(x<-x+a,  R)  = 

x + a 

which  suffices  for  the  sequential  case  must  be  replaced  by  the  definition 

wp(x«-x+a,  R)  = wp(xQ‘-x;  XQ»-XQ+a;  x<-xq,  R) 
where  Xq  is  a unique  temporary. 

The  fact  that  such  definitions  amount  to  explicitly  specifying  the  way  in  which  a given 
statement  must  be  compiled  is  somewhat  unfortunate  since  it  removes  much  of  the  option  of 
compiler  writers.  On  the  other  hand,  the  program  ADD2  can  have  entirely  different  behavior 
on  the  PDP-11  (where  memory  incrementation  is  a single  instruction)  than  on  the  IBM  360- 
370  series  (where  the  only  way  to  increrrient  memory  is  by  loading,  incrementing,  and  storing 
a register)  if  primitive  semantics  are  not  specified.  If  a concurrent  programming  language  is 
to  be  supported  on  different  machines  and  yet  produce  similar  results  for  any  given  program, 
its  semantic  definition  must  be  as  precise  as  we  have  indicated. 

4 2.2  Basic  Semantics 

In  order  to  build  up  gradually  to  the  general  case,  let  us  consider  the  semantics  of 
parallel  programs  which  consist  of  lexically  explicit  primitive  actions  and  which  consist  only 
of  sequences  of  assignment  and  when  statements^.  Then  the  semantics  of  such  programs 
(for  the  two  process  case,  with  the  obvious  generalization)  are  expressed  by 

wp(cobeRin  S j Si2i  • • -Sin  //  ^21'  ^22’  • • -^Zn  = 

wp({<5'|2i  ■''^21’  ^22'  ' ’ 

where 


Tk»  i1atsm»nl  when  B do  S od  means  "wait  for  B to  become  true,  then  execute  S"  The  evaluation  of  B and  the 
execution  of  S comprise  one  indivisible  action 
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1)  wp({],  R)  = R 

2)  wp({<>,  <S>},  R)  = wp({<5>.  <>],  R)  = wp({<5’>},  R) 

3)  wp({<5>},  R)  = wp(S,  R) 

wp({<5'^j;  S j 2’  • • ^^21'  ^22'  ' ■ ” 

wp(choose  1 from  ^^21'  ^22’  ' ' •’^5’  ^ 

wpfchoose  2 from  {<S j 5’;2'‘  • • ’ '^22’  • • 

5)  wp(choose  j from  {<Sjj;  Sj2>'  • • ^^21'  ^22'  ‘ ’ ” 

if  j = l then  wpCSj^;  {<-5'^2''  ■ • "^^21'  ^22'  ■ ■ 

else  if  j“2  then  wp(S2il  j [i  ^J2<  ■ • ^^22'  • • -^5.  R) 

6)  wp(J;  {P],  R)  = wp(S,  wp((P},  R)) 

The  primitive  actions  of  assignment  and  v/ hen -do  are  defined  as: 
p 1 ) wp(x*-e,  R)  =•  R|^ 

p2)  wpfwhen  B ^ S 0^  R)  = B A wp(S,  R) 

As  a brief  example,  consider  the  following  computation: 
wp(  cobegin 

P j : when  l=*0  ^ !♦- 1 T l»-0  // 

P2:  when  1=0  ^ l»-l  0^  T2;  l*-0 

coend 

, R)  “ 

wp({<ix//ren  f“0  L*-l  od;  T j;  l*-0>,  <when  L^O  do_  l*~I  od;  T 2',  R)  = 

wp(tt/Aien  L=0  ^ /*-)  gc^  \<T j;  <when  1=0  ^ L*-l  od:  T 2:  R)  A 

wp(u/_/jefl  do  l*-l  od;  {'^u/hen  1=0  do  l*-l  od;  T l<~0>,  2'%  R)  = 


1=0  A wp(Tj,  wp(t2,  R))  A wp{T2,  wp(Tj,  R)) 
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In  performing  the  above  computation,  no  simplification  can  be  done  until  the  expansion 
directed  by  rules  *3  and  5 is  finished.  If,  however,  we  choose  to  compute  strongest  post- 
conditions instead  of  weakest  pre-conditions,  we  obtain  some  reduction  in  the  complexity  of 
the  computation  since  simplification  may  be  done  along  the  way.  For  example,  in  the 
sequential  case  the  weakest  pre-condition  proof  of 

{-B}  if  B then  Sj  else  S2  LL  {^} 


involves  the  evaluation  of 


X - [B=»wp(S|,  R)]  A [-B  =»  wp(S2>  P)] 

and  the  subsequent  evaluation  of  -'B=»X.  Using  strongest  post-condition  directly  requires  the 
evaluation  of 


X - sp(S2,  -B) 

and  then  X=>R.  The  difference  is  primarily  a reduction  in  the  size  of  the  predicate  X. 

For  strongest  post-condition,  rule  ^ becomes 

sp({<Sjj;  S ^^21'  ^22’  • • •^}i  “ 

spfchoose  1 from  '^^21'  ^22'  • • 

spfchoose  2 from  Sj2i  ■ ■ •>.  '^^21'  ^22’  • ' 

with  rules  1-3  and  5-6  having  "wp"  replaced  by  "sp".  Rules  p2  and  p2  become 

p Is)  sp(x»-e,  R|*)  = R 
e 

p2s)  sp(wh^  B do  S qdj  R)  = sp(S,  B a R) 

Although  we  regarded  and  T2  as  primitive  m the  previous  exercise,  in  fact  the  same 
result  IS  obtained  when  Tj  and  T2  are  arbitrary  sequences  of  assignment  and  w_h^ 
statements  which  are  all  free  of  access  to  the  variable  L 

If  we  express  the  ADD2  program  of  section  4.2.1  m terms  of  its  primitive  actions: 

ADD2p:  cobegin 

ar-x;  a*-a+l;  x*-a  // 
br-x;  b«-b+l;  x*-b 
coend 
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we  find 


wp(Add2p,  x = 2)  = false 


and 


wp(Add2p,  x = l V x=2)  = (x=0) 


•i.2.2.1  Conditionals 

If  we  add  to  the  language  the  statement 

d B then  T ^ else  T2  h 

then  we  must  consider  that  even  if  B evaluates  to  true  at  some  point,  its  value  may  change 
by  the  time  T j is  actually  executed.  To  solve  this  problem  we  require  that  the  primitive  form 
of  a conditional  be  such  that  B contains  no  divisible  references  to  shared  variables,  and  T^ 
and  T2  are  themselves  in  primitive  form.  For  example,  the  statement 

d Cj  A C2  then  x'-x+l  else  y<->  -^1  fi. 

must  be  converted  to 
tl-cji 
t 1 *-t  1 A C2I 

d t j then  t2*"X;  t2‘~t2'*’li  x*-t2 
else  t^^y*,  t2*"t2'*'Ii 


fi 

We  can  then  modify  rule  5 to  be: 
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5')  wp(choose  j from  ’^■^2/’  ^22'  ' ' “ 

if  j«  1 then 

if  S j j is  "ij.  B then  T j T2  t!." 

then  [B  A wp({<r^;  Sj2!  ■ ■ ■>.  ^S2j;  522^  • • ->1-  ^>1 
[^B  A wp({<r2,-  Sj2;  . • •>.  '^22f  • • 

else  wptSjj;  ^2>  • • •^'  *^^21'  ^22*  • • 
else  if  j"'?  then 


■J. 2.2.2  Loops 

To  include  whi  e statements,  i.e. 


while  B ^ T od 

■whe'e  T and  B are  m primitive  form,  we  must  consider  that  although  the  boolean  B may 
evaluate  to  true  and  the  loop  may  be  entered,  B may  no  longer  hold  by  the  time  T is 
e»ecuted.  We  further  change  rule  5 to  be: 


5”)  wpfchoose  j from  Sj2’  • • ^^21'  ^22'  ‘ ' ” 

if  j-1  then 

if  Sj  J IS  "while  B ^ T od"  then 

[B  A wp({<7’;  while  B do^  T od;  ^i2'  • • ^^21'  ^22'  ‘ ' 

\y  [-B  A wp({<Sj2;  • • ^^21’  ^22’  ■ • 

else  if  Sj  1 is  "lI  B T 1 else  T2  li"  then 
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4.3.  Extending  the  Axiomatic  Approach 


4 3.1  The  Non-Interference  Principle 

Although  we  have  presented  on  the  previous  pages  a complete  semantic 
characterization  of  parallel  programs  which  consist  of  lexically  explicit  indivisible  actions,  tl'e 
complexity  of  that  characterization  effectively  prohibits  its  direct  application  to  verification. 
Most  of  the  difficulty  arises  from  the  fact  that  all  possible  execution  sequences  are 
individually  treated,  even  if  they  fall  into  large  equivalence  classes  based  upon 
indistinguishable  outcome.  For  example,  the  fact  that 

wp(  cobe.gin 

P j : while  x>0^x‘-x-l  od  // 

P2:  while  y>0  ^ y‘~y-l  od 

ccend 

.true) 

IS  equal  to  true  is  immediately  obvious.  However,  the  actual  weakest  pre-ccndition 
computation  as  defined  must  explore  the  hypothesis,  "Suppose  Pj^  executes  i cycles,  then  P2 
ea<ecutes  j cycles,  then  P^  executes  k cycles,  etc.,"  for  all  i,j,k,  etc.  All  such  execution 
sequences  are  equivalent  in  the  sense  that  there  is  nothing  one  process  can  do  to  affect  the 
other  in  any  way.  This  is  the  principle  of  non-interference  introduced  In  [Owicki  75].  We 
give  a precise  definition  in  our  own  terms. 

Let  {Pj  I j<l..n}  be  the  set  of  processes  of  a cobegin-coend  block,  and  let  each  process 
j be  represented  by  the  program 


^j0‘  Sjj;  . . . S 


where  each  Sj|^  is  a separate  statement.  Let  prooffQj,  Sj,  Rj)  be  any  sequential  proof  of 


r J' 


Qj  { Sj  } Rj 


i.e. 


{“j05  SjO  {“jl)  Sji  {r»j2}  ■ • • {“j,m+l) 

where  Qj=»ajQ,  ®j,rn+ 1 “j,k+p- 
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I rrooUOj.  Sj.  Rj)  I j(  l..n  } 

li  a proof  of  the  entire  prog' dm  ,f 

(V)<  l.  n)  (Vt«*0  m*  1 1 iV.dj)  (Vr'O.  m)  [a,|,  A wlpfS,^,  Oj|<,)] 

That  IS,  if  '’O  as'.e'*'C''  a , o‘  p'o:ess  j s interfered  with  (potentially  invalidated)  by  any 
statement  in  any  other  p'C  ess 

rjote  tria*  ■'  he  r'er*.  t'-'e  ‘ree  p'cpe'ty  is  not  satisfied,  that  does  not  necessarily 
mean  that  the  p'O^'a"-  s ' cpr'ect  ; ■ "-at  tne  individual  sequential  proofs  are  not  strong 
enough.  For  e»a'>'p  e,  a mq  e'^'  a o’ 

■t've;  B-  true,  A-true  {A} 


might  be 


{true}  5-true;  {true}  A-true  {A} 


or  it  might  be 


{true}  B-true;  {8}  A»-true  {A} 

The  former  will  not  confirm  non-interference  of  the  assertion  {A=»B}  since 

{A=»B  A true}  A«-true  {A=>B} 
is  not  valid,  while  the  latter  will  since 

{A=>B  A B}  A<-true  {A=>B} 

, IS  valid.  Note  that  it  is  not  necessary  that  a high-level  synchronization  mechanism  be  used  to 

I guarantee  mutual  exclusion.  For  example,  the  program 

cobegin 

while  x>0  do  x-x-2  o^  // 
while  x<0  ^ x-x+1  od 

coend 

has  the  proof 

I 
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: f 1 
CCbFg  - 

l*r  A '■>0  ^ >>o)  *'  t -2  •r.-2\  od  ;»-o  v *.-ij  // 
*^0  ^ (»<0)  >»i)  od  !*-o( 

cce'^d 

(*-o) 


4 3 2 Proving  Termir.3tion 


4.3.2. 1 Introduction 


OwicKi's  work,  which  is  h.'cpd  upon  the  non-interference  property,  dea'^  or  . w th 

weak  correctness.  We  shall  extend  the  utility  of  that  work  by  shewing  to  p'-  .e  lOp 
termination  for  parallel  programs.  A corollary  of  being  able  to  pro^e  loop  'c-rr  na*  o''  s,  O* 
course,  being  able  to  prove  that  a when  statement  will  eventually  be  e<ecutecJ,  •■r'.e  a :n 
statement  can  be  represented  as  a busy-wait  loop. 

4. 3. 2.2  The  Sequential  Case 

We  first  review  the  method  of  proving  sequential  loop  termination  p''''je''*ea  n 
[Oijkstra  76].  The  goal  is  to  find  a predicate  J which  satisfies 

J A wlp(S,  J)  =>  wpfwhile  B ^ S true) 

Let  t be  any  bounded  integer  funct  on  of  the  program  state,  i.e.  without  loss  of  generality 
t>0.  Furthermore,  suppose  that 

(1)  A B =►  t>0 

and  that  S decreases  t,  i.e.  if  T is  the  program  tQ*-f;  5,  then 
I (2)  J ^ B wp(T,  t<tQ) 

I 

Then  the  loop  must  surely  terrnmate,  since  (2)  guarantees  a steady  decrease  of  t and  (1) 
requires  that  when  t reaches  0 (as  it  must),  3 will  be  false  (because  J is  invariant).  For 
I example,  the  program 

[ while  j<N  ^ s<-s  + A[)];  jr-j  + l qd 


will  terminate  because  J -»  (s«  Z A[k])  is  invariant,  i.e. 

k”0 


* 


1 
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s = 


i-1 

I A[K]  A j<N 
k-0 


=»  s*A[j]=  i A[k] 
k-0 


(1)  IS  guaranteed  by  t-jNl-j*!,  since 


J A j<N  =»  lN|-j+l>0 


(2)  IS  guaranteed  also,  since 
J A j<N  =» 

wp(tQ*-lA/l-y* J;  s^s^Afj/;  |N|-j  + l'^tQ) 

lN|-j<|Nl-j  + l 
-1 

/ is  initially  satisfied  since  Z A[k]  = 0 holds  vaccuously,  and  t>0  is  initially  satisfied  since 
■^.3.2.3  The  Parallel  Case 

While  the  fact  that  this  simple  program  terminates  is  rather  obvious,  we  have 
presented  a rigorous  proof  so  that  we  may  now  observe  the  effect  of  other  processes  on 
the  method.  We  have  relied  heavily  on  the  fact  that  the  loop  body,  S,  decreases  the 
termination  function,  t.  This  need  not  be  true  for  parallel  programs,  for  example 

x^-N;  y*-0;  B‘-true; 

P;  cobeRin 

Li:  while  x>0  do  S|:  y*-(y+l)  mod  N B*-false  // 

L2:  while  B ^ S2:  x«-x-l  gd 

cgend 

At  this  point  it  IS  necessary  to  describe  the  behavior  of  the  cobegin-coend  block  more 
precisely.  In  [Brinch  Hansen  73],  the  program 

cobegin  S|  //  S2  //  • . -S^  coend 

is  said  to  behave  as  though  the  statements  are  executed  concurrently,  meaning  that  their 
executions  may  overlap  in  time.  This  definition  is  not  really  sufficient,  because  a uni- 
processor implementation  may  have  radically  different  behavior  from  a multi-processor 
implementation.  For  example,  suppose  that  the  process  scheduler  of  a uni-processor 
operating  system  does  not  limeslice  at  all.  Then  program  P above  will  definitely  ngj. 
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terminate,  since  there  is  never  any  reason  to  switch  processes.  Suppose,  on  the  other  hancJ, 
that  the  scheduler  does  timeslice.  Then  we  can  only  say  that  P may  terminate,  since  we  have 
not  prohibited  priority  scheduling  in  which,  for  example,  may  have  higlier  priority  than  L2- 

However,  if  each  process  is  assigned  its  own  processor,  program  P is  guaranteed  to 
terminate,  regardless  of  the  relative  speeds  of  the  individual  processors  (as  long  as  they  are 
finite). 


Since  we  must  choose  a suitable  definition  before  we  can  verify  programs,  we  will 
choose  the  multi-processor  case.  This  decision  is  not  at  all  arbitrary,  since  it  reflects  the 
current  trend  in  hardware  toward  distributed  processing  power. 

Returning  to  the  analysis  of  program  P,  suppose  we  wish  to  prove  termination  of  the 
loop  L^.  Clearly  the  function  governing  termination  is  t=pcs(x),  where 

pos(x)  = if  x<0  then  0 else  x 

Unfortunately,  Sj  does  not  affect  t,  although  $2  does.  Let  us  consider  sequential  proofs  of 
the  two  processes: 

x«-N;  y*-0;  B*~true; 

!B> 

cobe&in 

Lr-  Iff) 

while  x>0  do  IS)  S^:  y^-fy+l)  mod  N (S)  p_dj 
!x<0) 

B^-f  alse 
(«r<0  A -S)  // 

\-2‘  [true) 

while  B ^ jin/e)  S2:  x'-x-l  \tn,v)  pdj 

coend 
(rSO  A -S) 

Both  sequential  proofs  are  interference-free.  In  process  1 only  assertions  about  x are 
affected  by  process  2 and 


x<0  A true  x<0) 

In  process  2 only  assertions  about  B are  affected  by  process  1 and 

-'B  A x<0  =»  wlp(6<-/a(ie,  '8) 


64 


To  prove  termination  of  L|,  we  must  show  that  S2,  which  decrements  t=pos(x),  is  executed  a 
sufficient  number  of  times  to  reach  t=0.  This  is  clear  because  the  non-termination  of  L2. 

IS  invariant  across  5j.  Note  that  to  prove  termination  of  L2,  we  must  show  that  eventually 
"B‘'false"  is  executed,  and  we  have  that  as  a corollary  to  the  termination  of  L^.  In  light  of 
this  example  we  shall  try  to  formalize  a methodology  for  proving  termination  of  parallel 
programs.  First  we  introduce  some  important  concepts. 

We  define  a weak  Loop  invariant  to  be  any  predicate  which  always  holds  during 
execution  of  a loop  body,  not  just  at  entry.  For  example, 

while  true  ^ 

{A  A B] 

B*-f  alse; 

[A] 

B‘-true 

{A  A B\ 
od 

Here  only  {A}  is  a weak  invariant.  (We  call  it  weak,  even  though  its  invariance  requirement  is 
more  stringent,  because  it  must  be  a weaker  predicate  than  the  normal  loop  invariant.) 

A weak  parallel  loop  invariant  is  a weak  loop  invariant  for  which  a proof  of  non- 
interference can  be  exhibited. 

A steady-state  loop  invariant  is  any  predicate  which  is  guaranteed  to  be  satisfied  after 
a finite  number  of  executions  of  the  body,  and  which  remains  invariant  thereafter.  For 
example, 

x«-N;  A‘-false; 
while  true  ^ 

iT  x>0  then  x»-x-l  else  A<-true  h 
cd 

Here  {A}  is  a steady-state  loop  invariant.  Formally,  for  the  loop  while  B ^ S od.  P is  a 
steady-state  invariant  iff  at  entry 

[P  A B =*  wp(S,  P)]  A (3k)G^ 


where 


G 


0 


P 


^k+1  “ 


B A wp(S,  G|,_) 
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That  IS,  iff  P IS  Invariant  and  the  loop 

while  8 A 'P  do  S od 


terminates  by  establishing  P. 

A steady-state  weak  Loop  int/ariant,  by  analogy  to  the  distinction  between  a normal  and 
a weak,  invariant,  is  any  steady-state  loop  invariant  which  is  also  a weak  invariant. 

Finally,  a steady-state  weak  parallel  loop  invariant  is  a steady-stats  weak  invariant  for 
which  a proof  of  non-interference  can  be  exhibited. 

To  prove  termination  then,  we  proceed  as  follows; 


1)  Define  an  integer  function,  t,  of  the  program  state,  and  prove  t>0  is 
invariant. 

2)  Find  a steady-state  weak  parallel  invariant  J for  the  loop  in  question,  and 
prove 

A 8 =»  t>0 

3)  For  those  statements  (in  other  processes  and  within  the  loop  in  question) 
which  may  affect  the  value  of  t,  show  that,  in  any  state  in  which  J holds, 
none  of  these  can  increase  t unboundedly. 

A)  Show  that  in  any  state  in  which  a 8 holds,  some  statements  will  cause  a 
decrease  in  t. 

5)  Show  that  as  long  as  J a 8 holds,  statements  which  decrease  t must  continue 
to  be  executed. 

These  conditions  must  imply  termination  of  the  loop  in  question,  since  a steady  decrease  in  t 
and  (2)  imply  termination  when  t=0. 


4 3 3 An  Example 

We  illustrate  the  method  with  the  following  examiple,  which  provides  a fair  solution  to 
the  mutual  exclusion  problem  without  the  use  of  synchronization  other  than  busy  waiting. 
The  problem  was  first  discussed  in  [Dijkstra  65]. 
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Two  processes,  A and  B,  each  contain  a critical  section,  and  those  critical  sections  must 
be  prevented  from  executing  simultaneously.  Furthermore,  should  both  processes  desire 
execution  at  the  same  time,  the  decision  as  to  which  to  grant  permission  to  should  be  made 
on  an  alternating  basis. 

A solution  is  the  following; 

var  inA,  inB:  boolean  initially  false, 

P''ty;  (A,B)  initially  A; 


processA:  while  true  do 
<tbink> 


inAmfrue; 
while  inB  ^ 

iX  prty  = B then 
inAr-false; 

while  prty=B  do  nothing  od; 

inA*-true 

fi 


od; 

<critical  section> 
inA*-false; 
prty  — B 
qd 


processB:  while  true  do 
<think> 
inB'-true; 
while  inA  ^ 

X prty=A  then 
inB‘-f  alse; 

while  prfy=A  ^ nothing  od; 

inB<-true 

fi 


od; 

<critical  section> 
inB*-f  alse; 
prtyr-A 
od 


Weak  correctness  for  this  solution  is  established  by  the  following  proof,  which  is  easily  seen 
to  be  interference  free.  We  include  the  auxiliary  variables  critA  and  critB  in  order  to  be  able 
to  state  the  mutual  exclusion  requirement. 


67 


var  inA,  inB:  boo'ean(f alse), 
prty:  (A,B)(A); 

aux  var  critA,  critB;  booleao(false); 


processA;  while  true  do 
(,;r>s  A ~critA  A critB^'nB} 

*ithink> 

<A0,  inA»-true; 

{inA  A -cntA  a cr  tB^'i^B] 

<>91>  wh_'|e  '(crit A»-'in3)  ^ 

l/rrA  A -cntA  A crtfB^tnB) 

if  prty=B  then 
<.A2>  inA*-false; 

|-/n/5  A ~cntA  A critB-inB) 

<A3>  while  prty  = B ^ 

l~inA  A -cntA  a critB^mB) 

nothing 

od; 

A ~cntA  a cntB-mB  a prty-A] 
<AA>  inA«-true 
fl 

<AS>  [inA  A -cr/M  a cntB^mB  a prf/->l) 

od; 

(/p/5  A cntA  A -critB} 

<critical  sectiOn> 
crit  A*-false; 

[in A A -criM  A ~cntB) 

<A6>  inA'-false; 

A ~critA  A cnlB^inB) 

<A7>  prty*-9 

[-mA  A ^crilA  a crilB^inB] 
od 


processB;  while  true  ^ 

(-/nff  A -cn/S  A 

<think> 

<ffO>  ir.B^-true; 

(mS  A -criiB  a crif4=t<n/1} 

<SI>  while'  -(critB*-^inA)  do 
[inB  A -cnfS  a cr/M=»(ni4) 
if  prty=A  then 
<B2>  inB<-false; 

{-mS  A ^cnlB  a 

<S3>  v/hile  prty=A  ^ 

[~inB  A ^criiB  a cr/f-4=s/rT/4) 

nothing 

od; 

|-(n5  A -crilB  A cr/M='<n/>  A prty^B] 
<BA>  inBf-true 
fl 

<BS>  [inB  A -cntB  a cntA^inA  a prty^B] 

od; 

{/nff  A crifS  A 

<critical  section> 
critB*-false; 

[;nff  A -cnfff  A -erif/4) 

<BG>  inB*-false; 

l^mB  A A entA^inA) 

<B7>  prty-A 

{«mff  A -cnf3  A 

od 


Note  that  the  expanded  terrnination  conditions  of  the  original  "while  inA"  and  "while  inB" 
loops  (<B1>  and  <A1>)  are  quite  legal  on  the  grounds  that  we  have  simply  expanded  an 
indivisible  action  (the  evaluation  of  inA  or  inB)  into  one  which  is  guaranteed  to  terminate  and 
which  only  changes  variables  which  cannot  affect  the  program's  behavior. 
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4.3.3. 1 Weak  Correctness 


The  stated  assertions  follow  immediately  by  taking  successive  post-conditions  of  the 
input  assertions  which  appear  at  entry  to  the  outer  loops.  Furthermore,  each  assertion  is 
not  interfered  with  by  the  other  process.  We  present  two  illustrative  examples  of  what  must 
be  proven  to  guarantee  this. 

The  assertion 

{inA  A -critA  a critB=»inB  a prty=A} 

at  <AA>  is  not  interfered  with  by  the  assignment  at  <B2>  because 

(inA  A -^ritA  a critB=>in3  a prty=A)  A (-•inB  a -^ritB  a critA=>inA) 

=»  wlp(tnB«-/a(se,  (inA  a -critA  a critB=»lnB  a prty=A)) 

Furthermore,  the  same  assertion  is  not  interfered  with  by  the  assignment  at  <B4>  because  its 
conjunction  with  the  assertion  at  <Bi3>  is  false. 

Note  that  the  critical  sections  are  guaranteed  to  be  mutually  exclusive  (as  long  as  they 
don’t  alter  any  of  the  variables  inA,  inB,  and  prty)  because  the  assertions 

(inA  A critA  a -critB} 


and 


{inB  A critB  a ^critA} 


cannot  be  true  simultaneously. 

4.3.3.2  Strong  Correctness 

It  remains  to  be  proven  that  all  loops  (except  of  course  the  outer  ones)  terminate,  and 
hence  tne  critical  sections  will  be  executed.  We  will  prove  termination  for  process  A,  with  all 
arguments  symmetrically  applying  to  the  proof  of  termination  for  process  B. 
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Loop  <A3> 

1)  Let  t=0  iff  prty=A  and  t = l iff  prty=B.  Since  prty  is  of  type  (A,B),  t>0  is 
invariant. 

2)  Since  loop  <A3>  performs  no  actual  computation,  its  steady-state  weak 
parallel  invariant  is  identical  to  its  weak  invariant. 

J = -inA  A -critA  a critB=»inB 
Clearly  J A prty=B  =>  t>0. 

3)  The  valu.'i  ‘ prty  is  affected  only  by  statement  <B7>  in  process  B.  Smce 
prty*-A  corresponds  to  t«-0,  statement  <B7>  aces  not  increase  t. 

A)  If  A B holds,  then 

-•inA  A -critA  A critB=>inB  A prty=3 
so  t = l.  Thus  prty‘-A  will  decrease  t to  0. 

5)  The  only  way  that  <B7>  will  not  be  executed  is  if  loop  <B1>  does  not 
terminate  (assuming  the  critical  section  terminates).  Since  this  loop 
terminates  when  inA  is  false,  and  since  ^inA  is  guaranteed  by  the  steady- 
state  invariant,  non-termination  of  <B1>  can  only  be  a result  of  non- 
termination  of  an  inner  loop,  namely  <B3>.  Since  this  loop  depends  on 
prty=A,  and  since  prty=3  is  implied  by  a B,  <B3>  must  also  terminate. 

1-5  constitute  the  proof  that  loop  <A3>  (and  hence  loop  <B3>;  must  always  teTninate. 

Loop  <A1> 

1)  Let  t=0  iff  ^inB,  and  t = l iff  inB.  Since  inB  is  boolean,  t>0  is  invariant. 

2)  The  steady-state  weak  parallel  invariant  of  loop  <A1>  is 

J * inA  A -critA  a critB=>inB  a prty=A 


J is  established  after  the  first  pass  through  the  loop,  and  remains  true 
thereafter.  Clearly  J A inB  =>  t>0. 
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3)  The  value  of  t is  pofentially  affected  by  <B0>,  <B2>,  <B'3>,  and  <B6>. 

Statement  <B4>  cannot  affect  termination  of  loop  <A1>  because  its  pre- 

condition cannot  hold  at  the  same  time  as  J.  Since  inB  is  set  to  true  by 
<B0>,  that  statement  will  not  increase  t unboundedly. 

4)  Statements  <82>  and  <^B6>  can  potentially  decrease  t.  However,  because 

there  exists  a path  from  <B6>  to  a state  n which  mB  is  again  true,  we 

cannot  depend  on  <B6>  to  cause  te’’*"inahon.  existence  of  this  path  is 

reflected  by  the  fact  that  all  of  the  succe- s '.'e  asrc't'On's  bet^^,een  <36>  and 
<B0^  can  hold  at  the  same  time  as  J a B ~ oni,  remanmg  hope  is 

and  we  see  that  there  is  np  pa't"  '•O'r'  ■ ■ ■ ' > -'‘ite  i"  ,n3  is  reset 

to  true  before  <A1>  term. rates 

[J  A -inB  A -rf;3 
while  prty  do 
not  hmg 
od. 

{false) 

5)  It  remains  to  be  shown  tf-at  • s 
program  consists  of  stra;r*-t  r 
guaranteed  to  reach  <B1>  event. . a 'y 
guaranteed  to  enter  the  loop,  and  ,mi  e 
<B2> 

1-5  constitute  the  proof  that  loop  <’A1>  (and  nence  loop  <31>)  must  ai*a/s  terminate. 


e tne 

• I , *e  are 

r.  'r)x,  we  are 
■ ^ .,t  execute 
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5.  Verifying  Restricted  Parallel  Programs 


5.1.  Introduction 

In  this  chapter  we  take  a decidedly  different  approach  to  parallel  program  correctness 
from  those  of  Chapter  4.  By  restricting  the  syntax  of  parallel  programs  suitably,  we  can  be 
much  more  precise  about  their  semantics  and  more  practical  about  automating  a verification 
system. 


5.2.  Restrictions 

To  express  the  sem, antics  of  parallel  programs  precisely,  we  first  need  a working 
definition  of  what  parallel  program  correctness  means.  The  sequential  case  definition, 
termination  in  a particular  state,  will  do  only  when  we  deal  with  terminating  parallel 
programs.  Consider  parallel  programs  expressed  in  the  syntax; 

T;  cobegin  Ej  //  E2  //...//  coend 

and  let  us  restrict  the  Ej  to  be  single  conditional  critical  regions  [Brinch  Hansen  73]  of  the 
form: 

with  X|  when  B,  do  Sj  od 

We  can  express  the  correctness  of  program  T by  requiring  that  it  terminate  (i.e.  all  processes 
must  execute  and  terminate  individually)  in  a stale  which  satisfies  sorrie  relation  R. 

Operating  systems  frequently  contain  non-termmating,  cyclic  processes,  hence  no  final 
state  exists.  Consider  programs  of  the  form, 

\ 

C;  cobegin  repeat  E^  //  repeat  E2  //  . . . //  repeat  E^  coend 

where  repeat  <statement>  causes  infinite  repetition  of  <stalement>,  and  the  E|  are  as  before. 
Then  we  can  express  the  weak  correctness  of  program  C in  terms  of  the  achievemient  of  a 
state  satisfying  some  relation  R^,  whenever  process  j executes  Sj.  We  refer  to  this  as  weak 
correctness,  since  it  may  be  that  blocking  develops  (i.e.  all  processes  become  blocked  at  the 
same  time,  hence  no  further  progress  is  made),  or  it  may  be  that  one  or  more  processes 
deadlock  (i.e.  remain  blocked  forever  with  no  possibility  of  continuing).  Further,  one  or  more 
processes  may  starve  (i.e.  remain  blocked  forever  even  though  the  possibility  of  continuing 
exists).  Blocking,  deadlock,  and  starvation  are  called  strong  correctness  issues.  No  cyclic 
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parallel  program  may  be  considered  correct  unless  it  is  both  weakly  correct,  so  that  we  can 
describe  its  effect,  and  strongly  correct  (at  least  blocking-,  deadlock-,  and  probably 
starvation-free),  so  that  we  can  rely  on  the  weak  correctness  effect  being  achieved. 

We  have  recently  learned  of  the  work  of  van  Lamsveerde  and  Sintzoff 
[Lamsveerde  76],  which  uses  similar  ideas  in  an  effort  to  derive  strongly  correct  programs. 
Our  interest  is  in  verification  only. 


5.3.  Correctness  of  Terminating  Parallel  Programs 


For  program  T,  correctness  amounts  to  the  requirement  that  no  matter  in  what  order 
the  processes  begin  to  execute,  all  will  execute  (and  terminate)  eventually,  and  some  relation 
R w'lll  hold  when  all  are  finished. 

Let  <t(T)  be  the  index  set  of  processes  in  the  cobeRin-coend  block  T (i.e.  <r(T)  = {1,  2,  . . 
.,  n}).  Then 


wp(T,  R)  = wp((r(T),  R) 


where 

wp((^),  R)  = R 

wp(I,  R)  = (3j<I)(B^)  A (VjCl)[Bj  =»  wp(S^,  wp(I-{j},  R))] 


This  15  justified  as  follows.  We  claim  that  wpd,  R)  has  the  interpretation,  "No  matter  in  what 
order  the  processes  whose  indices  are  contained  in  Z execute,  all  will  execute  and  terminate, 
with  R established  at  the  finish."  We  show  this  by  induction  on  1Z|. 

For  1Z|=0,  i.e.  I=«ii,  the  interpretation  clearly  holds  since  wp(^,  R)  = R.  Assume  that  the 
interpretation  holds  for  |Z|  = k,  k>0.  Now  consider  Z’  -=  Z U ir,  where  ir/Z.  If  wp(Z’,  R)  is  to 
have  the  proper  interpretation,  then  it  must  guarantee  that  at  least  one  of  the  processes 
listed  in  Z’  is  runnable,  else  the  program  would  make  no  further  progress.  Also,  execution  of 
any  runnable  process  must  terminate  in  a state  which  assures  that  the  remaining  processes 
will  also  execute  and  finally  terminate  with  R.  This  is  exactly  what  is  expressed  by  wp(Z',  R), 
since  |Z’-{j}l=k  means  that  wp(Z’-{j],  R)  will  cause  the  remaining  processes  all  to  execute  and 
terminate  with  R by  the  induction  hypothesis. 

Finally,  since  ff(T)  contains  all  of  the  process  indices  of  program  T,  wp(<r(T),  R)  is  the 
desired  weakest  pre-condition. 
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5.4.  An  Example 

Consider  the  following  program: 

P:  cobegin 

with  X when  x=0  do  x*-2  od  // 
with  X when  x = l ^ x*-0  od  // 
^1^  X w_h^  x='2  ^ x*-l  cd 

coend 


Then  wp(P,  x=a)  = wp({l,  2,  3},  x=a) 

= (x=0  V x = l V x=2) 

A (x=0  =»  wp(x<-2,  wp({2,  3],  x = a))) 
A (x  = l ^ wo(x*-0,  wp({l,  3},  x=a))) 
A (x=2  =»  wp(x<-l,  wp({l,  2},  x=a))) 

1 ) wp({2,  3},  x = a)  = 

(x  = l V x=2) 

A (x  = l =>  wp(x*-0,  wp({3),  x=a))) 

A (x  = 2 =*  wp(x*-l,  wp{{2},  x = a))) 

= (x“l  V x*2) 

A (x  = l =»  wpfxi-O,  x = 2 A a = l» 

A (x=2  =>  wp(x<-l,  x = l A a=0)) 

=•  (x  = l V x=2)  A x?<l  A (x  = 2 ^ a=0) 

= x=2  A a=0 

2)  Similarly,  wp((l,  3},  x=a)  = (x=0  A a = l) 

3)  Similarly,  wp({l,  2},  x=a)  =•  (x  = l A a=2) 
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Hence  v«p((l,  2,  3],  x=a)  = 

(x=0  V x = l V x=2) 

A (x=0  =»  wp(x*-2,  x=2  A a=0)) 

A (x  = l =*  wp(x‘-0,  x=0  A a = D) 

A (x=2  =>  wp(x‘-l,  x = l A a=2)) 

= (x=0  V x = l V x=2)  A (x=0  =>  a=0)  a (x  = 1 =>  a = l)  a (x=2  =*  a=2) 

= x = a A (a=0  V a = l v a=2) 


5.5.  Correctness  of  Cyclic  Processes 


5 5.1  Weak  Ccrredness 

1 

I 

For  programs  of  the  form, 

C:  cobegin  repeat  //  repeat  E2  //  • • • //  repeat  E,^  coend 

I as  mentioned  in  section  5.2  we  define  weak  correctness  as  the  establishment  o^  some 

- relation  whenever  process  j can  execute.  Then 

I wlp(C,  <Ri,R2-  . ..Rn>)  = (Vj<l..n)  W^fC.  Rj) 


is  the  weakest  liberal  pre-condition  which  guarantees  this,  where 
Wj(C,  R)  = (Vk>0)  W^Nc,  R) 

vP{C,  R)  = =>  R 

R)  = (Vi<l..nl  [B,  =»  wlp(S,,  wNc,  R))] 

V 

W has  the  interpretation,  "If  there  is  some  sequence  of  process  executions  of  length  k 

which  results  in  B.  holding,  then  it  must  also  result  in  R."  This  is  clearly  satisfied  for  k=0. 

Assume  the  interpretation  of  holds  for  k>=m.  m>0.  Then,  since  guarantees  that  any 

executable  process  will  resull  in  w"^.  the  interpretation  must  hold  for  all  k>0.  The 
k J ’ ' 

conjunction  of  W.  for  all  k>0  then  has  the  interpretation,  "Any  sequence  of  process 
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executions  which  results  in  3j  holding  will  also  result  in  R holding",  thus  whenever  process  j 
can  run,  will  be  true. 


5 5 2 Strong  Correctness 
b.5.2.1  Blocking 

A set  of  processes  is  blocked  if  none  of  them  can  run,  thus  allowing  no  further 
progress.  A cyclic  parallel  program  is  blocking- free  if  there  is  no  execution  sequence  which 
leads  to  blocking.  For  program  C,  the  weakest  pre-condition  which  guarantees  that  C is 
blocking-free,  denoted  wbp(C),  is  given  by 

wbp(C)  = (Vk>0)  L^fC) 


where 


Uq(C)  >=  true 

= (3j<l..n)(Bj)  A (VjU..n)  [B^  ^ wp(Sj,  U^(F))] 

U(^(C)  has  the  interpretation,  "At  least  k processes  will  execute."  This  is  clearly  satisfied  for 
k=0.  For  Uj,  + j(C),  we  must  have  that  at  least  one  process  can  execute,  and  that  any  process 
that  does  execute  will  result  in  U)^(C),  which  is  precisely  what  is  expressed  above.  In  the 
limit,  Uj^(F)  will  guarantee  an  unbounded  execution  sequence,  and  hence  that  F is  blocking- 
free. 

5.S.2.2  Deadlock 

If  a cyclic  parallel  program  reaches  a state  which  forever  excludes  any  possibility  of  a 
given  process  continuing,  then  that  process  is  said  to  be  deodiocked^  A cyclic  parallel 
program  is  deadlock-free  if  there  is  no  execution  sequence  which  leads  to  the  deadlock  of 
any  process.  The  weakest  pre-condition  which  guarantees  program  C to  be  deadlock-free, 
denoted  wdpiC),  is  given  by 

wdp(C)  = wbp(C)  A (ViU..n)  (Vj(l..n)  W,(C,  V(C,  B^))) 


where  Wj  is  as  previously  defined  in  section  5.5.1  and 


V(C.R)  = (3k>0)  V|,{R) 

Vq(R)  = R 

V;^^j(R)  = (3mU..n)(8^  a wp(S^.  V^(R))) 
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V(C,  Bj)  gives  the  weakest  pre-condition  that  assures  the  existence  of  an  execution  sequence 
which  establishes  W|(C,V(C,Bj))  thus  gives  the  condition  which  guarantees  the  continued 
existence  of  such  a sequence  whenever  process  i is  executable.  The  definition  of  wdp  may 
be  read,  "All  processes  must  leave  invariant  the  condition  which  assures  the  possibility  of 
any  given  process  executing". 

5.5. 2. 3 Starvation 

A process  is  said  to  starve  if  it  is  prevented  from  '-unning  by  virtue  of  the  pa'^ticula" 
execution  sequence  taken  by  the  parallel  p'^cgram,  while  in  fact  it  would  become  runnable  if 
some  other  execution  sequence  had  been  chosen.  This  is  to  be  distinguished  from  deadlock, 
in  which  a state  is  reached  from  which  r^  execution  sequence  can  enable  a given  process. 
The  weaKest  pre-condition  guaranteeing  non-starvation  in  a system  of  parallel  processes, 
wzp{C),  is  given  by 


wsp(C)  = wbp(C)  A (Vi<  1 ..n)-'V(C,  Z(-3j)) 


where 

Z(R)  = (Vk>0)  Z^(R) 

Zq(R)  = R 

Z^.,j(R)  = (3jU..n)(B^  A wp(Sj,  Z^(R))) 

Z(R)  gives  the  weakest  pre-condition  that  assures  the  existence  of  an  unbounded  execution 
sequence  which  maintains  the  truth  of  R.  That  is,  Z(--Bj)  holds  if  and  only  if  B|  is  false  and 
can  be  kept  forever  false  by  some  execution  sequence.  V(C,  R)  is  as  defined  in  the  previous 
section,  so  -V(C,  Z(-B,))  guarantees  that  it  is  not  possible  to  reach  a slate  in  which  process  i 
can  be  forever  prevented  from  running. 
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5 5 3 Verification  Methods 

Having  described  the  weakest  pre-condition  formalism  for  the  class  of  programs  with 
which  we  are  concerned,  we  now  discuss  an  approach  to  parallel  program  verification  which 
IS  analogous  to  the  invariant  relation'  approach  to  sequential  loop  correctness  (see  section 
4. 3. 2. 2). 


Theorem  5.1  (Non-blocking  Invariant) 

(Vj(  l..n)  A =>  wp(Sj,  J)]  /\[J  ^ (3j<  l..n)Bj] 
h [J  =*  wbp(C)] 


Proof 


Rewriting  the  theorem,  we  must  show 

(Vjc  l..n)  A Bj  =*  wp(Sj,  ,;)]  A [J  =>  (3jU..n)Bj)]  /\  S ^ (Vk>0)U^^ 

where 

Uq  = true 

'-'k+l  “ (3j« l..n)(Bj)  A (VjcL.nKBj  =*  wp(Sj,  Uj^)) 

We  use  induction  on  k. 

1)  For  k*0,  the  theorem  clearly  holds. 

2)  Suppose  (Vjfl..n)  [jt  a B^  wp(Sj,  J)]  a [j  (3j<  i..n)Bjj  a ^ U,^- 

Then  we  will  prove 

(Vjcl..n)  [J  A Bj  =»  wp(Sj,  J)]  A [ j =>  (3j<  l..n)Bj]  a ^ =» 

That  is, 

(Vj<  1 ..n)  A Bj  =»  wp(Sj,  J)]  U =»  (3j<  1 ..n)Bj]  a ^ a ^ ^ 
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Substituting  the  definition  of 

(Vja..n)  U A Bj  ^ wp(Sj,  m A [J?  =»  (3jU..n)Bj]  a ^ a 

=»  (3jU..n)Qj  A (Vj<l..n)  [Bj  wp(Sj,  Uj^)] 

Since  we  can  derive  (3j^l..n)Bj  from  the  hypotheses  immediately,  it  remains 
to  show 

(Vj«  l..n)  [J  A Bj  =»  wp(Sj,  J)]  A [j/  =»  (3j^ l..n)Bj]  a ^ a U|,^ 

=»  (Vj(l..n)  [B^  =>  wp(Sj,  U^)] 

We  can  assume  J =»  since  otherwise  the  implication  clearly  holds. 

Then  (Vj<  l..n)  [Bj  =>  wpfSj,  J)]  =»  (Vj(  l.,n)  [Bj  =>  wp(Sj,  U|^)] 

O 

from  the  monotonicity  of  wp  . 


Theorem  5.2  (Non-deadlock  Invariant) 

(Vj(  l..n)  A Bj  ^ wp(5j,Jf)]  A [J  =*  (3ja..n)Bj]  a (Vj(  l..n)  [J  V(C,  Bj)] 

I-  [,^  =»  wdp(0] 


See  Appendi*  A 


Theorem  5.3  (Ncn-$ta^v e tion  Invariant) 

(Vj(  l..n)  A Bj  =»  wp(Sj,  ;)]  A [ j =»  (3j(  l..n)Bj]  a (VjU..n)  [J  =»  'Z('Bj)] 

h [J  =>  wsp(0] 


The  proofs  of  these  theorems  are  sufficiently  similar  to  that  of  the  non-blockmg  theorem 
as  to  make  their  inclusion  unnecessary. 


5 5.4  An  Example 

We  shall  prove  that  the  following  program  is  blocking-free  using  Theorem  5 1: 
assert  n>0  a 0<x<n  a 0<y<n  a 0<z<n  a 0<x+y+z<3n; 
cobegin 

with  (x,y)  when  x>0  a y<n  ^ x*-x-l;  y*-y  + l qd  // 
with  (y,z)  when  y>0  a z<n  ^ y’-y-l;  z-z+1  qd  // 
with  (z,x)  when  z>0  a x<n  ^ z<-z-l;  x<-x  + l qd 

coend 

This  program  models  the  action  of  three  processes  moving  data  among  three  buffers,  e.g. 
cobegin 

q‘-remove(bj);  insert(f(q),b2)  // 
r‘-remove(b2);  insert{g(r),b0)  // 
s*-remove(b3)j  inserf(h(s),b ^ ) 

ccend 

Let  us  take  the  input  assertion  to  be  our  invariant  J.  Then  we  must  prove, 
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1)  (Vj(l..n)  A Bj  =»  wp(Sj,  J)] 

2)  i^GjU..n)e^ 

Proof 

1.1 ) jf  A Bj  =*  wpfSj,.^) 

n>0  A 0<x<n  A 0<ysn  a 0<z<n  a 0<x*y+z<3n  A x>0  a y<n 
=»  wp(x‘->-l;  y«-y  + l,  j) 

n>0  A 0<x<n  A 0<y<n  a 0<z<n  a 0<x+y*z<3n 

=»  n>0  A i<x<n  + l A -l<yin-l  a 0<z<n  a 0<x+y+z<3n 

1.2)  J A 02  =*  wp(S2>  J)  by  symmetry 

1.3)  ^ A 00  =»  wp(S3,  J)  by  symmetry 

2)  J ^ (3j«  l..n)  Bj 


i 


f 


ri>0  A 0<x£n  A 0<y<n  a 0<z<n  a 0<x-^y+z<3n 

(x>0  A y<n)  V (y>0  a z<n)  v (z>0  A x<n) 

(x<0  V y>n)  A (y<0  V z>n)  a (z<0  v x>n) 

=»  n<0  V x<0  V x>n  v y<0  v y>n  v z<0  v z>n  v x+y+z<0  v x*y+z>3n 

(x<0  A y<0  A z<0)  V (x<0  A y<0  A x>n)  V (x<0  A z>n  a z<0) 

V (x<0  A z2n  A x>n)  v (y>n  a y<0  a z<0)  v (y>n  a y<0  a x>n) 

V (y>n  A z>n  A z<0)  v (y>n  a z>n  a x>n) 

=»  n<0  V x<0  V x>n  v y<0  v y>n  v z<0  v z>n  v x+y+z<0  v x+y  + z>3n 

which  can  be  seen  to  be  true  by  inspection. 
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6.  Conclusions 


In  this  last  chapter  we  shall  attempt  to  draw  the  thesis  together  in  a coherent  fashion. 
Section  6.1  contains  a summary  of  the  material  presented  in  each  chapter.  Section 

6.2  describes  what  we  think  are  the  contributions  made  by  the  thesis.  In  section 

6.3  we  present  our  evaluation  of  the  feasibility  of  operating  system  verification. 
Section  6.4  describes  what  we  regard  as  important  areas  for  future  research. 


6.1.  Summary 

In  Chapter  2 we  presented  a methodology  for  the  design,  specification,  implementation, 
and  verification  of  highly  modular  programs.  The  methodology  relies  upon  the  concept  of  an 
abstract  data  type  to  provide  well-defined  module  boundaries  which,  by  virtue  of  their 
encapsulation  of  low-level  data  structure  access,  also  conveniently  encapsulate  the 
verification  of  data  structure  consistency.  Based  upon  the  comparison  of  several 
specification  techniques,  one  was  chosen  which  we  think  provides  the  most  intuitive  means  of 
transforming  ideas  into  mathematical  form  during  the  process  of  formal  specification.  The 
example  of  a queue  was  used  in  each  case  to  provide  a basis  for  comparison.  Once  a 
decision  was  m.ade  as  to  the  nature  of  formal  specifications,  we  described  a method  of 
ve-^ifying  their  consistency  by  proving  the  invariance  of  certain  properties  of  the  abstract 
state. 


Chapter  3 expanded  upon  the  methodology  of  Chapter  2 in  order  to  investigate  its 
applicability  to  the  design  and  verification  of  operating  systems.  The  relationship  between 
the  structure  of  a system  and  the  language  in  which  it  is  implemented  w'as  explored.  If  the 
system  is  hierarchically  structured,  then  the  implementation  language  used  to  construct  one 
level  is  a combination  of  that  used  to  implement  the  level  below  and  the  facilities  changed  by 
the  level  below. 

Chapter  3 also  contains  a large  example  - the  design,  specification,  implementation,  and 
verification  of  the  process  dispatcher  of  a hypothetical  system.  Particular  emphasis  was 
placed  on  verifying  the  specifications  in  addition  to  the  implementation.  Using  the  proof 
technique  outlined  in  Chapter  2,  properties  such  as  "the  current  process  has  highest  priority" 
and  "dispatching  is  done  in  Round  Robin  fashion"  were  shown  to  be  true  of  any 
implementation  which  correctly  models  the  specifications. 

Because  operating  systems  employ  much  concurrency  in  their  implementation,  we 
devoted  the  next  two  chapters  to  various  approaches  to  verifying  the  total  correctness  of 
parallel  programs.  In  Chapter  4 we  explored  two  of  these,  one  using  Dijkstra’s  weakest  pre- 
condition semantics  [Dijkstra  76],  and  the  other  using  the  axiomatic  weak  correctness 
approach  of  Owicki  [Owicki  75].  Both  were  applied  to  a general  class  of  parallel  programs. 
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The  'AeaKest  pre  cone  f'On  joprsach  to  verif/mg  general  parallel  programs  led  to  the 
r cQUi r erne p t ter  much  more  ri^crousl/  speC't  pd  semantics  of  sequential  control  constructs, 
because  these  are  usually  maoe  up  ot  r.everal  primitive  machine  instructions,  after  any  one  of 
which  pre-emption  may  occur.  The  result  was  a complete  but  computationally  difficult  proof 
technique  for  the  parallel  control  construct. 

Owicki's  axiomatic  approacn  is  less  algorithmic,  because  it  requires  the  insightful 
addition  of  auxiliary'  variables.  Howeve’’,  it  is  more  feasible  computationally.  Also  in  Chapter 
4 then,  we  presented  our  own  interpretation  of  her  methodology,  including  the  princip'e  of 
non-interference,  and  discussed  an  approach  to  verifying  termination  which  generalized 
Dijkstra’s  approach  for  the  sequential  case  [D'jkstra  76]. 

In  Chapter  5,  we  returned  to  the  weakest  pre-condition  approach,  but  applied  it  to  a 
restricted  class  of  parallel  programs.  The  restrictions  allowed  us  to  formally  define  the 
weakest  pre-conditions  which  guarantee  both  weak  correctness  and  the  absence  of  blocking, 
deadlock,  and  starvation.  Although  these  definitions  are  complex,  we  were  able  to  formulate 
theorems  which  make  use  of  the  invariant  relation  concept  in  order  to  guarantee  correctness. 
Several  examples  were  presented. 


6.2.  Contributions  of  the  Thesis 

Following  are  what  we  consider  to  be  the  contributions  miade  by  this  research.  The 
order  in  which  they  are  presented  is  not  intended  to  convey  any  idea  of  relative  importance, 
but  IS  based  more  or  less  sequentially  upon  the  material  presented. 

1)  The  idea  of  developing  an  imiplementation  language  hierarchically,  based 
upon  the  structure  of  the  system  it  is  being  used  to  implement. 

2)  The  idea  of  casting  the  correctness  of  formal  specifications  in  terms  of 
invariants  whic  i relate  the  data  types  involved,  and  the  method  of  verifying 
these  invariants.  This  includes  the  notion  that  such  abstract  ideas  as 
"fairness"  can  be  verified  of  the  specifications  if  they  can  be  expressed  in 
terms  of  these  invariants. 

3)  The  fact  that  the  design,  implementation,  and  verification  of  a small  but  fairly 
realistic  part  of  an  operating  system,  the  process  disoatcher,  was  shown  to 
be  relatively  straightfor ward  using  the  proposed  methodology. 

4)  The  predicate  transformational  appro aci  to  parallel  program  correctness, 
most  importantly  the  char acterization  of  weakest  pre-conditions  (or  weak 
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correctness,  absence  of  blocking,  deadlock,  and  starvation,  and  the 
formulation  of  invariant  relation  theorems  for  those  concepts. 

5)  The  extension  of  the  weak  correctness  methodology  of  Owicki  [OwicKi  75] 
to  include  the  proof  of  arbitrary  parallel  program  loop  termination.  This 
includes  the  generalization  of  Dijkstra’s  methodology  for  sequential  loop 
termination  [Dijkstra  76]  and  the  concept  of  a "steady-state"  loop 
invariant. 


6.3.  On  the  Feasibility  of  Operating  Systems  Verification 

After  expending  a good  deal  of  effort  on  the  research  described  in  the  thesis,  and  in 
light  of  our  resulting  experience,  it  would  seem  appropriate  that  we  comment  upon  the 
possibility  of  carrying  out  the  verification  of  an  entire  operating  system. 

The  primary  problem  we  encountered  during  the  process  of  carrying  out  program 
proofs  was  the  inappropriateness  of  pencil  and  paper  to  the  task.  Much  of  the  work 
m\'Olved  was  tedious,  requiring  continuous  re-copying  of  non-trivial  assertions  in  order  to 
effect  the  step-by-step  transformations  dictated  by  weakest  pre-conoition  computation.  This 
particular  process,  usually  called  verification  condition  (VC)  generation,  is  undoubtedly  best 
handled  automatically  by  a computer  program,  and  indeed  numerous  implementations  of  such 
programs  exist,  for  example  [Suzuki  75,  Good  75].  We  made  a conscious  decision  neither 
to  implement  nor  to  use  an  existing  VC  generator,  principally  because  we  desired  the 
freedom  of  not  fixing  a syntax  for  our  implementation  language.  Since  for  any  real  attempt 
at  verification  of  an  entire  operating  system  we  could  easily  write  a VC  generator,  much  of 
this  tedium  should  disappear  in  practice. 

There  is  no  question  that  a powerful  automatic  theorem  proving  system  is  also  needed. 
Most  of  the  quantifier-free  verification  conditions  could  be  proved  rather  easily  by  a 
relatively  simple  deductive  system,  but  owing  to  the  nature  of  the  abstract  data  type 
mechanism,  assertions  which  are  quantified  over  types  are  very  common.  For  example,  an 
invariant  which  describes  doubly-linked  circular  lists  of  objects  of  type  T is 

(Vx(T)  (x.succ.pred  = x a x.pred.succ  =•  x) 

The  proof  of  the  procedure  appendR  of  type  Multiq  in  Chapter  3 relies  very  heavily  on  this 
invariant,  and  no  simple-minded  theorem  prover  can  handle  it  In  our  ooinion  however,  a 


^ We  m f»ct  tried  out  the  proof  of  i PASCAL  version  of  tlie  procedure  on  bolti  SuzuXi's  verifier  [Suzuki  75]  and 

the  ISI  verifier  [Good  75]  without  success  This  is  not  to  say  that  some  other  equivalent  definition  of  correctness 
couldn't  b«  us*d  pfoductfv«fy  in  this  csss,  bcit  w»  w»sh  to  stick  to  our  commsots  sbout  srec«fic»tton  techniques  in 
Chapter  2 
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highly  interactive  theorem  prover  could  substitute  human  intelligence  for  a sophisticated 
automatic  deduction  system  with  great  success,  since  after  all  very  few  candidate  theorems 
derived  from  computer  programs  require  continuous  creativity  to  be  proven. 

In  addition  to  the  VC  generator  and  interactive  theorem  prover,  a VC  generatoi"  for 
specifications,  as  discussed  in  section  2.3,  should  be  part  of  any  system  used  to  verify  large- 
scale  programs.  Furthermore,  the  entire  verification  system  must  be  part  of  a total  system 
development  environrrient  in  which  there  exist  representations  of  inter-mc  .lule  dependencies. 
This  bookkeeping  system  must  have  the  knowledge  to  invalidate  and  regenerate  the  proofs 
of  modules  which  are  potentially  affected  by  changes  to  other  modules.  Because  of  the 
^heer  size  of  this  sort  of  information  in  a real  system,  there  is  no  hope  of  ever  remembering 
such  dependencies  without  machine  assistance.  An  attempt  along  these  lines,  although  for 
the  moment  primarily  concerned  with  documentation  and  inter-modul  vei'Sion  consistency,  is 
described  in  [Habermann  77].  Work  is  also  in  progress  to  formialize  both  inter-  and  mtra- 
module  dependencies  [Cooprider  77],  and  this  shouid  serve  as  a basis  for  the  exploration 
of  a development  and  maintenance  environment  for  correct  programmed  systems. 

It  is  not  clear  that  the  method  of  describing  data  structures  by  type-quantified 

invariants  as  we  have  used  them  is  sufficient.  A m.ajor  problem  is  the  use  of  recursive 
functions  in  these  assertions.  For  example,  a binary  tree  may  be  described  by  the  invariant 

(Vxfnode)  btree(x) 

where  btree(x)  = if  x = null  then  true  else  btree(x.left)  a btreefx. right). 

The  function  btree  is  only  partial  if  there  is  a path  from  any  node  to  itself.  Dealing 
with  such  assertions  is  quite  complicated,  and  it  remains  to  be  seen  if  the  data  structures 
used  by  an  operating  system  can  all  be  simple  enough  to  avoid  these  complications. 

Finally,  our  parallel  program  correctness  work  is  only  a basis  for  future  work.  Smce 
no  real  operating  system  will  use  conditional  critical  regions  because  of  their  inherent 

implernent ation  ine^f iciency,  more  work  must  be  done  on  using  the  critical  region  formal  basis 
to  deal  with  more  practical  synchronization  primitives.  Some  of  this  has  lately  been  done, 
and  IS  described  in  [Flon  77].  An  introduction  to  various  synchronization  primitives  and 
their  verification  may  be  found  in  [Andler  77]. 

The  conclusion  we  draw  from  this  evaluation  of  the  feasibility  of  operating  system 

verification  is  that  it  hinges  upon  the  development  of  a powerful  programming  and 

verification  environment  and  the  further  investigation  of  parallel  program  correctness  as 
described  above.  There  is  every  reason  to  believe  that  five  years  to  a toy  environment  and 
system,  and  ten  to  a practical  environment  and  system  are  fair  estimates. 
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6.4.  Areas  of  Importance  for  Future  Research 

As  mentioned  in  the  preceding  section,  there  remain  several  important  and  interesting 
problems  to  be  solved  before  we  can  hope  to  achieve  a verified  operating  system.  We  list 
what  we  consider  to  be  the  three  most  important. 

1)  Can  the  process  of  verifying  the  correctness  of  procedures  which  manage 
complex  data  structures  be  made  sirnpler  by  judicious  choice  of  the 
consistency  invariant,  or  is  some  other  method  of  specification  needed? 

2)  What  should  be  the  attributes  of  an  environment  for  the  development  and 
maintenance  of  correct  programs?  What  should  the  user  inter'ace  to  an 
inte-active  program  verification  system  be?  Can  program  verification  be 
done  incrementally?  That  is,  can  a modified  program  be  re-verifled  only 
insofar  as  is  absolutely  necessary? 

3)  How  can  we  apply  the  parallel  program  correctness  ideas  of  Chapters  4 
and  5 to  practical  synchronization  mechanisms?  There  has  been  work  done 
on  proving  the  correctness  of  concurrently  used  abstract  data  types 
[Howard  76,  Flon  75,  Owicki  77]  but  very  little  has  been  said  about 
the  correctness  of  processes  which  use  those  data  types.  What  effect  do 
monitors  and  path  expressions  have  on  the  provability  of  absence  of 
deadlock?  (Campbell  has  done  an  investigation  of  this  question  for  highly 
simplified  path  expressions  [Campbell  76].) 

The  area  of  large-scale  program  construction,  maintenance,  and  verification  should  provide  a 
rich  source  of  interesting  research  questions  over  the  years  to  come. 
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Appendix  A:  Weakest  Pre-Condition  Semantics 


Definition 


The  u/eakest  pre-conditLon  of  a statement  S and  predicate  P,  wp(S,  R)  is  the  necessary 
and  sufficient  condition  which  guarantees  that  S will  terminate  leaving  R true. 


1)  wp(<empty>,  R)  = R 

2)  wp(x<-e,  R)  = R|^ 

All  free  occurrences  of  x in  R are  replaced  by  e. 

3)  wp(d  B thsiQ  S|  else  $2  tij  P)  = 

[B  =>  wp(Sj,  R)]  A [-B  =»  wp(S2,  R)] 

4)  wp(S|;S2.  w'p(S2>  R)) 

5)  wpfwhile  B GO  S R)  = (JK)  Gj^ 

where  Gq  = -B  a R 

^k  + 1 - B A wp(S,  G(^) 


ji 


Definition 

The  ijyeakest  UberaL  pre-con.ditt.on  of  a statement  S and  predicate  R,  wlp(S,  R)  is  the 
necessary  and  sufficient  condition  which  guarantees  that  S will  either  terminate  leaving  R 
true  or  not  terminate  at  ail. 


wp(S,  R)  - wlp(S,  R)  A wp(S,  true) 


An  important  property  of  the  weakest  pre-condition  is  monotonicLty,  which  is 
expressed  by  the  axiom 
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P =»  Q I-  wp(S,  P)  ^ wp(S.  Q) 

Since  wp(S,  P)  characterizes  the  set  of  slates  which  guarantee  the  truth  of  P after  S is 
executed,  any  one  of  those  states  must  also  guarantee  the  truth  of  Q after  S as  long  as  P=>Q. 


Weakest  pre-condition  has  a dual,  called  strongest  post-condition. 


Definition 


The  strongest  post-condition  of  a statement  S and  predicate  R,  sp(S,  R),  is  the 
strongest  possible  characterization  of  the  set  of  states  which  can  held  after  S terminates, 
given  that  it  is  started  with  R holding. 


1)  sp(<empty>,  R)  = R 

2)  sp(x-e,  R|^)  = R 

3)  sp(d  B then  S|  else  $2  li.  P)  “ 

[R  A B =>  sp(S^,  R)]  A [R  A -B  =>  sp{S2i  R)] 
“3)  sp(Sj;  $2>  R)  = sp(S2,  sp(Sj,  R)) 

5)  spfwhile  B ^ S R)  = 'B  a (3K) 

Fq  = R 

Rk  + 1 " 


where 
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Appendix  B:  Primitive  Abstract  Data  Types 


The  definitions  we  present  are  in  the  style  of  [Hoare  72a]. 

Notation 

X:t  means  X has  type  t. 

Enumeration  Types 

1)  The  type  (dj,  62,  . ■ .d^)  where  n>l  and  the  dj  are  distinct  identifiers  is  called  an 
enumeration  type. 

2)  If  x:(dj,  d2,  . . -d^)  then  (3j(l..n)  x=dj. 

3)  (VjU-.n)  dj^l>dj 

Range  Types 

A range  type  is  an  enumeration  type,  denoted  a..b,  whose  elements  are  a contiguous 
subset  (from  a to  b)  of  the  elements  of  another  enumeration  type,  e.g.  l..n  is  a range  type  of 
the  integers. 

Records 

1)  If  aj:t j,  a2:t2>  • • -an'^n  ^'^7  *ypes  tj,  then 

(ai,a2,  . . .a„)  : d i:< 

for  any  identifiers  fj. 

2)  x:(fi:ti,  f2:t2,  ■ ■ -fn=*n^  x=(ai.  ^2<  ■ ■ -®n^  x x.f2=a2,  . . .x.f^-a^. 

if  x:(f  a2>  • • '®n^ 

<x,  fj,  k>.f^  = if  j=m  then  k else  x.f^ 


3) 


Vectors 


The  rules  for  vectors  are  taken  from  [Luckham  76]. 

1)  If  D is  an  enumeration  type  and  R is  any  type,  then  vector  D of  R is  a vector  type. 
Let  X:vector  D gj.  R. 

2)  (Vd(D)  (X[d](R) 

3)  <X,  d,  r>[d’]  = if  d’=d  then  r else  X[d’] 

4)  j = (>k)P(X[k])  = P(X[j])  A (Vk>j)^P(X[k]) 

• j=  (<k)P(X[k])  5 P(X[j])  A (Vk<j)-P(X[k]) 

Sequences 

1)  If  R is  any  type,  then  sequence  gj,  R is  a sequence  type. 

Let  Xrsequence  of  R. 

2)  If  r<R  then  either 

2.1)  X-r 

2.2)  X=X  (a  distinguished  symbol) 

2.3)  X-r~Y  where  Y:sequence  gf,  R 

3)  first(x):  sequence  gj  R -*  R 

3.1)  if  X-r  then  r 

3.2)  if  X=\  then  undefined 

3.3)  if  X-r-'Y  then  r 

4)  has{X,k):  sequence  gf  R x R -►  boolean 

4.1 ) if  X-r  then  (r-k) 

4.2)  if  X»\  then  false 

4.3)  if  X-r-'-Y  then  (r-k)  v has(Y,K) 

5)  length(X):  sequence  gj  R -*  integer 


5. a)  if  X=r  then  1 

5.2)  if  X=X  then  0 

5.3)  if  X-r~Y  then  l+length(Y) 

6)  equal(X.Z):  sequence  gl  R x sequence  of  R -•  boolean 

if  X=X  A Z=X  then  true 

else  if  X=r  a Z»s  then  (r=s) 

else  if  length(X)j<length(Z)  then  false 

else  (X=r-Xp  a (Z»s-Zp  a (r«s)  a equaKXj.Zj) 
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